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Sir: 

Pursuant to the Notice of Appeal filed on March 16, 2010 in connection with the 
above-identified patent application, Applicants respectfully submit the instant Brief on 
Appeal in accordance with 37 C.F.R. § 41.37. This Brief is being submitted with a petition 
and fee for an extension of time pursuant to 37 C.F.R. § 1.136. 



I. Real Party In Interest 

The Nielsen Company (US), LLC is the real party in interest to this appeal. The 
above-referenced patent application has been assigned to The Nielsen Company (US), LLC, 
by Nielsen Media Research. The assignment has been recorded in the United States Patent 
and Trademark Office ("PTO") at Frame 0259 of Reel 023030. The above-referenced patent 
application was previously assigned to Nielsen Media Research by the inventors, Daozheng 
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Lu, Paul Kempter, and William Feininger. The assignment to Nielsen Media Media 
Research has been recorded in the United States PTO at Frame 0302 of Reel 021622. 

II. Related Appeals and Interferences 

The Applicants are unaware of any related appeals or interferences. 

III. Status of the Claims 

Currently, claims 13-21, 28-39, 61-69, 79-90, 92-94, 99-100, and 102 are pending in 
this application. Claims 1-12, 22-27, 40-60, 70-78, 91, 95-98, 101, and 103 are canceled. 
The pending claims are presented in the Claims Appendix of this Brief. Claims 13-21, 28-39, 
61-69, 79-90, 92-94, 99-100, and 102 stand rejected under 35 U.S.C. § 103. Therefore, 
claims 13-21, 28-39, 61-69, 79-90, 92-94, 99-100, and 102 form the subject matter of this 
appeal. 

IV. Status of the Amendments 

The amendments that were made in this application have been entered. No 
amendments were filed after the final Office action. 

V. Summary of the Claimed Sub ject Matter 

Although reference numerals and specification citations are inserted below in 

accordance with C.F.R. 41.37(c)(l)(v), these references numerals and citations are merely 

examples of where support may be found in the specification for the terms used in this 

section of the brief. There is no intention to in any way suggest that the terms of the claims 
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are limited to the examples in the specification. Although, as demonstrated by the reference 

numerals and citations below, the claims are fully supported by the specification as required 

by law, it is improper under the law to read limitations from the specification into the claims. 

Pointing out specification support for the claim terminology as is done here to comply with 

rule 41.37(c)(l)(v) does not in any way limit the scope of the claims to those examples from 

which they find support. Nor does this exercise provide a mechanism for circumventing the 

law precluding reading limitations into the claims from the specification. In short, the 

reference numerals and specification citations are not to be construed as claim limitations or 

in any way used to limit the scope of the claims. 

Independent claim 13 is directed to a system. The television audience measurement 

system (60, 100, 200, 300, 400) for digital television (66, 1 10, 224, 324, 410) is disposed in a 

statistically selected location (62, 102, 202, 302, 402). (See, e.g., FIGS. 2-6 and paragraphs 

[0035], [0044], [0054], [0057], [0063], [0066], [0073], and [0074]). The system includes a 

software agent (112, 118, 122, 500) and a communication apparatus (114, 116, 120, 124, 

170). (See, e.g., FIGS. 3 and 7 and paragraphs [0046]-[0048], [0050]-[0051], [0079]-[0090]). 

The software agent is adapted to read a program identification (PID) header from a data 

packet containing a portion of a tuned digital television program to identify the television 

program tuned by the digital television equipment. (See, e.g., Abstract, FIGS. 2, 4, 5, and 7, 

and paragraphs [0015], [0035]-[0038], [0040] -[0041], [0053], [0056], [0061], [0064], [0079], 

and [0081]). The software agent is stored in memory associated with the digital television 

equipment, and the PID header is broadcast with the data packet to enable the digital 

equipment to tune to a selected one of a plurality of minor channels broadcast in a major 

channel. (See, e.g., FIG. 3 and paragraphs [0007], [0015], [0045]). The software agent stores 
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at least a portion of the PID header in association with a timestamp. (See, e.g., FIG. 3 and 
paragraphs [0003], [0019], [0046]-[0048]). The communication apparatus is adapted to 
transmit at least one of the at least the portion of the PID header and media identification 
information obtained via the PID header to a remotely located central office. (See, e.g., FIG. 
3, 4, and 6, and paragraphs [0015], [0050], [0061], [0071], [0078]). 

Independent claim 61 is directed to a tangible computer-readable storage medium 
including a set of instructions. The set of instructions, when executed, provide a software 
agent (1 12, 1 18, 122, 500) stored in memory associated with digital television equipment. 
(See, e.g., FIG. 3 and paragraphs [0015] and [0045]). The software agent is arranged to 
acquire television audience measurement data relative to the digital television equipment. 
(See, e.g., FIGS. 3 and 7 and paragraphs [0007], [0015], [0019], [0045]-[0048], and [0079]- 
[0087]). The software agent includes first instructions to store and timestamp at least a 
portion of a television program identification (PID) header from a data packet containing a 
portion of a tuned television program to identify the television program selected for viewing 
on the digital television equipment. (See, e.g., FIG. 3 and paragraphs [0003], [0019], and 
[0046]-[0048]). The software agent includes second instructions to log a co-transmitted 
datum transmitted in a same major channel as the television program selected for viewing on 
the digital television equipment, the co-transmitted datum being related to the tuned 
television program. (See, e.g., FIG. 7 and paragraphs [0019]-[0020] and [0083]-[0084]). 
The software agent includes third instructions to log an Internet identification datum 
associated with an Internet task of the digital television equipment. (See, e.g., FIGS. 3 and 7 
and paragraphs [0010], [0020], [0051], [0084]-[0085], and [0092]). 
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Independent claim 62 is directed to an apparatus. The apparatus is provided for 
identifying a viewer selected television program from among a plurality of time overlapped 
television programs broadcast in a viewer selected broadcast channel and received by digital 
television program reception equipment. (See, e.g., FIGS. 3 and 7 paragraphs [0007], [0015], 
[0019], [0045H0048], and [0079]-[0087]). The digital television program reception 
equipment has a data port to export tuned data. (See, e.g., FIGS. 3, 4, and 6, and paragraphs 
[0027], [0046H0048], [0050], [0072], and [0075]-[0077]). The apparatus includes a reader 
connected to the data port to read program identifying data tuned by the digital television 
program reception equipment from among data exported from the digital television program 
reception equipment via the data port for use by a media device different from the digital 
television program reception equipment. (See, e.g., FIGS. 3 and 6, paragraphs [0045]- 
[0048], [0050], [0072], [0074]-[0078]). The data port operates in accordance with the IEEE 
1394 protocol and the program identifying data read by the reader are identifier tags exported 
with the data in accordance with the IEEE 1394 protocol. (See, e.g., FIGS. 3 and 6, 
paragraphs [0050] and [0078]). The apparatus also includes a memory to store the program 
identifying data. (See, e.g., FIGS. 3 and 7, and paragraphs [0003], [0045], and [0082]). 

Independent claim 79 is directed to a method. The method is implemented by a 

software agent stored in memory associated with digital television equipment. (See, e.g., 

FIG. 3 and paragraphs [0015] and [0045]). The software agent is arranged to acquire 

television audience measurement data relative to the digital television equipment. (See, e.g., 

Abstract, FIGS. 2-5 and 7, and paragraphs [0015], [0035]-[0038], [0040]-[0041], [0053], 

[0056], [0061], [0064], [0079], and [0081]). The method includes storing and time stamping 

at least a portion of a television program identification (PID) header from a data packet 
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containing a portion of a tuned television program to identify the television program selected 
for viewing on the digital television equipment. (See, e.g., FIG. 3 and paragraphs [0003], 
[0007], [0015], [0019], [0045H0048]). The method includes logging a co-transmitted datum 
transmitted in a same major channel as the television program selected for viewing on the 
digital television equipment, the co-transmitted datum being related to the tuned television 
program. (See, e.g., FIG. 7 and paragraphs [0019H0020] and [0083]-[0084]). The method 
includes logging an Internet identification datum associated with an Internet task of the 
digital television equipment. (See, e.g., FIGS. 3 and 7, and paragraphs [0010], [0020], 
[0051], [0084H0085], and [0092]). 

Independent claim 80 is directed to a method. The method is provided for identifying 
a viewer selected television program from among a plurality of time overlapped television 
programs broadcast in a viewer selected broadcast channel and received by digital television 
program reception equipment, wherein the digital television program reception equipment 
has a data port to export tuned data to a second media device. (See, e.g., FIGS. 3 and 5-7, 
and paragraphs [0007], [0015], [0019], [0027], [0045]-[0048], [0050], [0072], and [0075]- 
[0087]). The method includes intercepting program identifying data tuned by the digital 
television program reception equipment from among data exported from the digital television 
program reception equipment via the data port. (See, e.g., FIGS. 3 and 5-6, and paragraphs 
[0045H0048], [0050], [0072], [0074]-[0078]). The data port operates in accordance with the 
IEEE 1394 protocol, and the program identifying data includes identifier tags exported with 
the data in accordance with the IEEE 1394 protocol. (See, e.g., FIGS. 3 and 6, and 
paragraphs [0050] and [0078]). The program identifying data is exported to the second 
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media device and stored. (See, e.g., FIGS. 3 and 7, and paragraphs [0003], [0045], and 
[0082]). 

VI. Grounds of Rejection To Be Reviewed on Appeal 

The grounds of rejection to be reviewed on appeal are as follows: 

Ground 1. Whether claims 13-21, 28-39, 61, 79, 88-90, 92-93, and 99 are 

unpatentable over Houston (U.S. Patent 6,353,929) in view of Ozkan 
(U.S. Patent 6,031,577). 

Ground 2: Whether claims 62-69, 80-87, 94 and 102 are unpatentable over 
Houston in view of Welsh (U.S. Patent 5,374,951) and Saito (U.S. 
Patent 6,751,221).. 

VII. Ar2ument 

Ground 1. Claims 13-21, 28-39, 61, 79, 88-90, 92-93, and 99 are 
patentable over the Houston/Ozkan combination 

A. The Art Does Not Teach Timestamping PIDs As Recited In Claim 13 

Claim 13 is directed to a new type of audience measurement system for monitoring 

digital television broadcasts. Importantly, the audience measurement system of claim 13 

includes a software meter to collect and timestamp PID (Packet IDentification) headers. PID 

headers are expressly defined in claim 13 to be "broadcast with the data packet to enable the 

digital equipment to tune to a selected one of a plurality of minor channels broadcast in a 

major channel." The art as of the priority date of this application (May 12, 1998) did not 

teach or suggest timestamping PID headers. On the contrary, PID headers were used or 

contemplated for use by tuning equipment for tuning a user selected channel from a digital 

television broadcast. None of the art relied upon by the Examiner has any indication 

whatsoever that PID headers have any use for audience measurement or that there would be 

any need at all for timestamping PID headers as contemplated by claim 13. Instead, all of the 

audience measurement art relied upon by the Examiner either ignores the presence of PID 
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headers or merely references the use of PID headers for their conventional tuning purposes. 
As such, absent hindsight reference to the applicants' disclosure, no person of ordinary skill 
in the art would have arrived at the combination of claim 13 as of the May 12, 1998 priority 
date based on the art relied upon by the Examiner. 

More specifically, claim 13 is patentable over the Houston/Ozkan combination 
employed by the Office action. To understand why, it is important to first understand the 
basics of digital television transmission. Digital television transmission systems were known 
prior to the invention of the instant application. Such systems involve the packetization and 
broadcast of content over channels located at certain agreed frequencies. Each of these 
frequencies defines a single major channel. Each major channel has sufficient bandwidth to 
simultaneously carry multiple programs, if desired, or to carry a single high resolution 
program. These programs carried within a major channel are referred to as minor channels or 
sub-channels. The programs to be broadcast as minor channels are converted to digital 
packets, multiplexed, and then broadcast as a stream of packets at the frequency defined by 
their corresponding major channel. Each program is typically associated with a stream of 
audio packets and a stream of video packets as well as other control or data streams. Thus, a 
tuner that has been instructed to tune to minor channel 1 associated with program 1 carried on 
major channel 200 is faced with the problem of determining which of the packets it is 
receiving on major channel 200 are to be presented to the viewer. 

In order to enable the tuner to distinguish between the various packets in the 

multiplexed steam (and, thus, to tune the appropriate minor channel), every broadcast packet 

is labeled with an identifier known as a Packet IDentification (PID) header. The PID header 

will, thus, for example, identify its packet as associated with one of the minor channels 
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carried in the tuned major channel. As a result, the tuner can quickly tune to the appropriate 
minor channel requested by the viewer by displaying only those video packets and playing 
only those audio packets labeled with the PID headers indicating they are associated with the 
minor channel to be tuned, and discarding all packets labeled as associated with other minor 
channels by comparing the PID headers of the streaming packets to a PID provided by the 
user via channel selection. 

Importantly, PID headers are re-used for different programs at different times. Thus, 
as a simple example, PID #2 could be used to broadcast "Friends" at 6PM on Thursday on 
major channel 200 and PID #2 could again be used broadcast the local news at 6:30PM on 
that same day on the same major channel 200. Thus, PIDs are intended to enable a tuner to 
distinguish between multiplexed program streams received at a given moment in time , but are 
not intended to distinguish between programs from time to time or across major channels. 
Another way to put this is PID headers are for tuning and, thus, to distinguish streams of 
packets multiplexed in the same major channel, but are not intended to identify program 
content in a universal sense. Thus, in the above example, the same program "Friends," might 
be broadcast on another day on the same channel at the same time, but using an entirely 
different PID (e.g., PID #3). 

Against this backdrop, one can immediately see that, absent hindsight reference to 

applicant's disclosure, it is far from clear that PIDs would be of use for an audience 

measurement entity seeking to determine which of the many available programs on the many 

available major and minor channels are tuned. Indeed, the USPTO has previously 

recognized this very point. To better understand this, it is necessary to consider some 

history. In particular, claim 13 of this application was originally rejected based on Aras, US 

9 
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Patent 5,872,588 (Office action of October 19, 2005). This was a very surprising turn of 
events because it flatly contradicted a prior ruling by a Reexamination Examiner of the 
USPTO that, Aras provided no motivation to store PID information in association with 
timestamps. In particular, the parent of this application, namely, US patent application serial 
number 09/076,517 (the "parent application") includes claims which were copied in an effort 
to provoke an interference with Massetti, U.S. Patent 5,974,299 (the "'299 Patent"). 

The very same examiner who examined and allowed the Massetti 4 299 Patent, 
rejected the claims copied from the Massetti '299 Patent in the parent application as 
unpatentable over Aras et al. This was another surprising turn of events because the parent 
application has an earlier filing date than the 4 299 Patent and the Aras et al. reference was 
considered by that same examiner during the proceedings which led to the issuance of the 
4 299 Patent. Since the examiner found the copied Massetti claims patentable over Aras et al. 
in the context of the 4 299 Patent, logical consistency demanded that those same claims would 
be patentable over Aras et al. in applicants' earlier filed application; unless, of course, the 
USPTO acted in error in allowing the 4 299 Patent. 

In view of the USPTO' s inconsistency, the applicants for the parent application 
responded by traversing the rejections. In response, the Examiner sustained his rejections 
based on Aras et al. and implicitly invited the applicants to file a request for reexamination of 
the '299 Patent. Therefore, the applicants filed a request for reexamination of the Massetti 
4 299 Patent based on the Aras patent and other references. 

In the reexamination of the 4 299 Patent (Control No. 90/007,057), the USPTO 
ultimately issued a notice of allowance stating: 
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Aras fails to teach or suggest recording the PID . . . 
along with the time [of] reception, in that Aras teaches 
recording the payload data of the PID> and which has more 
information than the PID alone. Consequently, there is no 
motivation to store the PID information of Aras in that the Aras 
system already has similar information (derived from the 
payload portion but not the PID per se). 

(Control No. 90/007,057, Notice of Intent to Issue Ex Parte Reexamination Certificate dated 
April 3, 2006, Statement of Reasons for Patentability and/or Confirmation, Pages 12- 
13)(emphasis added). Therefore, the USPTO has previously concluded that Aras does not 
teach or suggest a software agent adapted to read and timestamp a program identification 
(PID) header to identify a television program tuned by digital television equipment as recited 
in claim 13. On the contrary, as noted by the USPTO in its earlier decision, "Aras teaches 
recording the payload data of the PID." (Id.) Because the payload data "has more 
information than the PID alone," the USPTO had previously concluded that "there is no 
motivation to store the PID information of Aras." (Id.) 

Fast forwarding to the instant application on appeal, we find that the Examiner 
previously rejected claim 13 as unpatentable over Aras in the Office actions of October 19, 
2005 and June 15, 2006. The applicants pointed out to the Examiner of the instant 
application that the USPTO had previously correctly concluded that there was no motivation 
to modify Aras to collect and store PID headers because Aras already had access to the 
payload information. Faced with this inconsistency, the Examiner of the instant application 
replaced Aras with Houston, US Patent 6,353,939, in each of the rejections. 

In response, the applicants pointed out that substituting Houston for Aras resulted in 
the exact same deficiency. In particular, because Houston teaches collecting payloads of 
packets associated with the PID headers for exactly the same reason the USPTO had 
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previously concluded that there was no motivation to modify Aras to collect the PID headers 
themselves, there was similarly no motivation to modify Houston to collect such PID 
headers. The Examiner, however, disagreed and maintained the rejections based on Houston. 
(See Office action dated August 1, 2007). 

Faced with this intransigence of the Examiner and the inherent contradictions between 
the positions taken by the Examiner in this application and the conclusion reached by the 
USPTO in the earlier Massetti reexamination, the Applicants contacted John Houston, the 
named inventor of the Houston Patent, and asked him to evaluate the positions taken by the 
Examiner. Mr. Houston was available for contact because the Houston Patent has been 
assigned to the assignee of the instant application, and because John Houston was a paid 
consultant of the assignee. The Applicants sought Mr. Houston's candid view of the 
rejections based on the Houston Patent. As shown in the 132 Declaration submitted with the 
December 3, 2007 response, Mr. Houston affirmed that his patent neither disclosed nor 
suggested collecting PID headers as recited in claim 13. In particular, Mr. Houston testified: 

5. With respect to independent claims 13, 61 and 79 of the 4 224 
application as presented with the Response to the Office action of August 1, 
2007 filed herewith, my patent makes absolutely no mention of collection 
and/or timestamping PID headers as a useful vehicle for performing media 
monitoring. While it is true that the methods and apparatus disclosed in my 
patent could certainly collect such PID headers (the methods and apparatus I 
disclosed can be used to collect virtually any type of media measurement 
data), my patent does not specifically disclose the concept of collecting 
and/or timestamping such PID headers or in any way indicate that 
collecting and/or timestamping such PID headers would be of interest. 
Therefore, in my opinion, the only way a person of ordinary skill in the art at 
the relevant time frame reading my patent would be led to collect and 
timestamp PID headers, is if that person had a priori knowledge of the value 
of collecting such PID headers from another source. 

6. I agree with the position that my patent described collecting 
payload data which may be associated with PID headers and, thus, my 
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patent does not by itself motivate someone to collect and timestamp PID 
headers. 

(132 Declaration of John Houston, Paragraphs 5 and 6)(bold & Italics added, underlining in 
original). Therefore, Mr. Houston unmistakably agreed that his patent, like Aras, did not 
"motivate someone to collect and timestamp PID headers." (Id at Para. 6). This is 
completely consistent with the USPTO reexamination examiner's above discussed prior 
ruling in the Massetti reexamination that "there is no motivation to store the PID information 
of Aras in that the Aras system already has similar information (derived from the payload 
portion but not the PID per se). M (Control No. 90/007,057, Notice of Intent to Issue Ex Parte 
Reexamination Certificate dated April 3, 2006, Statement of Reasons for Patentability and/or 
Confirmation, Pages 12-13). Thus, the applicants have provided significant evidence that the 
invention of claim 13 was not obvious in view of the cited art. This evidence is further 
explained in the following. 

The Houston/Ozkan Combination Fails to Meet Claim 13 

As noted above, claim 13 is directed to a television audience measurement system 
comprising a software agent to read a program identification (PID) header from a data 
packet containing a portion of a tuned digital television program to identify the television 
program tuned by the digital television equipment, wherein the software agent stores at least 
a portion of the PID header in association with a timestamp. The Office action rejected 
claim 13 based on a combination of Houston and Ozkan, US Patent 6,031,577. However, the 
combination of Houston and Ozkan is in error because it is not supported by logical 
motivations for making the same. Moreover, even if one were to combine Houston and 
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Ozkan, one would not arrive at the system of claim 13 as the Houston/Ozkan combination 
does not result in a system that stores at least a portion of a PID header in association with a 
timestamp. 

Elements Missing From The Houston/Ozkan Combination 

Houston discloses a cooperative media handler to present content to users and provide 
information about the presentation of that content and user interactions therewith to an 
audience measurement company. (See Houston, US Patent 6,353,929, Col 5, lines 5-63). 
However, Houston makes no mention whatsoever of PID headers or that collecting and 
timestamping such PIDs would be of any use. Indeed, as noted above, Houston himself 
testified that the Houston Patent "does not specifically disclose the concept of collecting 
and/or timestamping such PID headers or in anyway indicate that collecting and/or 
timestamping such PID headers would be of interest." (132 Declaration of John Houston, 
paragraph 5). Therefore, Houston does not teach or suggest a software agent that "stores at 
least a portion of the PID header in association with a timestamp" as recited in claim 13. 

Ozkan, US Patent 6,031,577, is directed to "the formation of Program guides, system 

information and program specific information." (Ozkan, Col. 1, lines 13-15). Ozkan 

certainly uses PIDs, but they are used for tuning sub-channels. They are nowhere 

timestamped or in any way identified as something useful for audience measurement 

purposes. In the words of Ozkan: 

The corrected output data from unit 17 is processed by MPEG 
compatible transport processor and demultiplexer 22. The individual packets 
that comprise either particular program channel content, or program specific 
information, are identified by their Packet Identifiers (PIDs). Processor 22 
separates data according to type based on an analysis of Packet Identifiers 
(PIDs) contained within packet header information and provides 
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synchronization and error indication information used in subsequent video, 
audio and data decompression. 

The corrected output data provided to processor 22 is in the 
form of a transport datastream containing program channel content and 
program specific information for many programs distributed through several 
sub-channels. The program specific information in this exemplary description 
describes sub-channels present in a transport stream of a particular PTC. 
However, in another embodiment the program specific information may also 
describe sub-channels located in other PTCs and conveyed in different 
transport streams. Groups of these sub-channels may be associated in that their 
source is a particular broadcaster or they occupy the transmission bandwidth 
previously allocated to an analog NTSC compatible broadcast channel. 
Further, individual packets that comprise a selected program channel in the 
transport stream are identified and assembled by processor 60 operating in 
conjunction with processor 22 using PIDs contained in the program specific 
information. 

The program specific information is in the form of 
hierarchically arranged tables including an MGT, CIT, EIT, and ETT together 
with supplementary descriptor information. The PID that identifies packets 
comprising the MGT data is predetermined and stored within processor 60 
internal memory. Further, the MGT conveys the PIDs that identify the CIT, 
EIT, and ETT data and conveys other information indicating the size of these 
tables. Processor 60 monitors the MGT for updates to identify any changes in 
PIDs or table sizes. Therefore, after processor 60 determines from the FEC 
lock indication provided by unit 17 that valid data is being provided to 
transport processor 22, the MGT may be acquired without additional PID 
information. Using Control signal C, processor 60 configures transport 
processor 22 to select the data packets comprising the remaining program 
specific information including the CIT, EIT and ETT data. Processor 22 
matches the PIDs of incoming packets provided by unit 17 with PID values 
pre-loaded in control registers within unit 22 by processor 60. Further, 
processor 60 accesses, parses and assembles the program specific information 
packets captured by processor 22 and stores the program specific information 
within its internal memory. Processor 60 derives tuning parameters including 
PTC carrier frequency, demodulation characteristics, and sub-channel PIDs, 
from the acquired program specific information. Processor 60 uses this 
information in configuring units 13> 15> 17 and decoder 100 elements to 
acquire selected sub-channel (SC) program content. 

(Ozkan, Col. 5, lines 10-63)(emphasis added). Thus, Ozkan clearly recognizes the known 

presence of PIDs in digital television broadcasts and uses them for their convention tuning 

purposes. However, there is no mention of timestamping PIDs or transmitting PIDs to a 
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remote location for any audience measurement purpose. Thus, both Houston and Ozkan fail 
to teach or suggest a software agent that "stores at least a portion of the PID header in 
association with a timestamp" as recited in claim 13. Given that these same elements are 
missing from both Houston and Ozkan, the Houston/Ozkan combination likewise suffers 
from this same missing elements. Accordingly, the system of claim 13 is patentable over the 
Houston/Ozkan combination. 

The False Motivations Cited by the Examiner 

The Office action cites three alleged motivations for combining Houston and Ozkan 
to attempt to recreate the invention of claim 13. All three motivations are fanciful, 
inconsistent with the evidence of the state of the art at the time of the invention, and cannot 
be used to support the rejections of claim 13. The alleged motivations for combining 
Houston and Ozkan appear on Pages 9-10 of the Office action Mailed September 17, 2009 
and are demonstrated to be false in the following. 

The First False Motivation 

The Examiner alleges: 

At the time of the invention, it would have been obvious to one of 
ordinary skill in the art to use the PID headers taught by Ozkan in the system 
disclosed by Houston. 

The first motivation would have been that using a standardized 
program identifier, such as a PID header, would have given the system better 
interoperability with existing systems, which would be an advantage as 
Houston deals with the sharing of viewing records. 
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(Office action dates September 17, 2009, Page 9). This alleged motivation is almost 

incomprehensible in its vagueness. First of all, the motivation fails to identify any "existing 

systems" that lacked interoperability with Houston. It likewise fails to identify any way in 

which any alleged instance of this unknown and unidentified interoperability would actually 

be improved by collecting PIDs. Further, it fails to explain any way in which PIDs are 

standardized in a manner relevant to audience measurement generally or to the Houston 

system specifically. Further, it explains no way in which collecting PIDs with Houston 

would actually improve the sharing of viewing records and, thus, achieve the alleged 

"advantage." The soft and amorphous nature of this alleged motivation and its underlining 

statements is not surprising because they have no basis in fact. 

As explained above, PID headers are used for distinguishing packets for minor 

channels that are broadcast together in a major channel. While they are standardized in the 

sense that they are defined as a certain 13 bits in the header of broadcast digital television 

packets, it is far from clear that this standardization has any bearing on Houston or the 

audience measurement Houston seeks to perform. On the contrary, as known to those of 

ordinary skill in the digital television art, PIDs are not intended to distinguish between 

programs from time to time or across major channels. Thus, there is no standardization of 

PIDs in a sense that would suggest they are useful for audience measurement. Moreover, 

there is nothing in Houston to suggest that there is any lack of interoperability that would be 

addressed by collecting PID headers. Indeed, it is important to note that the Houston system 

contemplated monitoring satellite television (i.e., digital, packetized television broadcasts). 

(Houston, USP 6,353,929 at Col. 4, lines 23-28). Despite the fact that the Houston system 

was adapted to measure digital television broadcasts, the inventor, John Houston himself, 
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testified, "Therefore, in my opinion, the only way a person of ordinary skill in the art at the 
relevant time frame reading my patent would be led to collect and timestamp PID headers, is 
if that person had a priori knowledge of the value of collecting such PID headers from 
another source." (132 Declaration of Houston, paragraph 5). 

Ozkan does not provide any such a priori knowledge. As discussed above Ozkan uses 
PIDs, but for their conventional tuning purpose. There is no indication in Ozkan that PIDs 
should be timestamped or that they have any value for audience measurement purposes. 

In short, the alleged "first motivation" is completely without basis in fact. On the 
contrary, it is naked conjecture that pales to inconsequence in view of the solid evidence 
provided by the applicants. The KSR decision of the US Supreme Court did not give 
examiners license to reject claims based on artificially manufactured motivations. While 
Examiners are certainly to use common sense in making patentability determinations, they 
are not to depart from reality nor are they to require applicants to tilt with the windmills of 
the examiner's imagination in order to prove their entitlement to a patent. This first 
motivation is nothing more than the product of a creative mind using knowledge of the 
invention to seek a reason to patch references together for the sole reason of rejecting a claim. 
It is not the product of common sense reasoning that would have been employed by a person 
of ordinary skill in the art at the time of the invention and it is not a proper basis for rejecting 
claim 13. 

The Second False Motivation 

The Examiner alleges: 

The second motivation would have been that using the PID header 
enables the system to tune to a sub-channel without acquiring the program 
map table (PMT)(Ozkan, column 7, lines 47-54). 
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(Office action dates September 17, 2009, Page 9). This statement betrays a superficial 
understanding of the Houston and Ozkan Patents that would not have characterized the 
person of ordinary skill in the art. First of all and as explained above, the use of PIDs is 
fundamental to tuning of digital programming. As also mentioned above, Houston monitored 
digital television broadcasts. (Houston, USP 6,353,929 at Col. 4, lines 23-28). As such, the 
systems Houston monitored were quite capable of tuning to sub-channels apart from any need 
to reference Ozkan. Further, Houston is directed to a system for monitoring exposure to 
media. It is not directed to a system to tune such media. As such, a person of ordinary skill 
in the art reviewing the audience measurement system of Houston would not be looking for 
ways to improve the operation of the tuning systems Houston monitors and, thus, would 
never be incentivized by the second alleged motivation. In the words of Mr. Houston 
himself: 

My patent is directed toward an audience measurement system. It is 
not a tuning device and it does not seek to affect how audience members 
utilize their tuning devices nor does it seek to affect how such tuning devices 
operate to tune programs. Instead, specifically with respect to tuning devices, 
my patent relates to measuring how audience members utilize their own tuning 
devices. As such, there is no reason apparent to me to modify my patent to 
enable tuning of any sort, let alone to enable tuning "to sub-channels 
without acquiring the program map table (PMT)" as stated in the Office 
action. 

(132 Declaration of John Houston, Paragraph 3)(emphasis added). 

Second, while Ozkan is certainly directed to modifying tuning systems to tune to a 
sub-channel without acquiring the program map table (PMT), Ozkan does NOT do this by 
introducing PIDs. Rather, Ozkan assumes that PIDs are present, since as explained above, 
PIDs are an inherent requirement of the digital broadcasting system. Rather, Ozkan is 
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directed to utilizing a Service Location Descriptor map in place of a Program Map Table to 

achieve more efficient tuning. In the words of Ozkan: 

The SLD program map information replicates information already 
present within the Program Map Table (PMT) segment of the MPEG 
compatible transport stream input to decoder 100. However, by incorporating 
the SLD within the CIT> the time required by decoder 100 to identify and 
acquire a program being transmitted on selected sub-channel SC is 
advantageously reduced. This is because the CIT and SLD provide formatted 
and linked information sufficient to enable processor 60 to directly configure 
and tune the system of FIG. 1 to receive the selected sub-channel SC. 
Specifically, the CIT and SLD directly associate individual first and second 
sub-channel identification numbers with the PIDs for identifying the 
datastreams that constitute a program being conveyed on this sub-channel. 
This enables processor 60 to configure the system of FIG. 1 to receive the 
selected sub-channel SC without acquiring and using the Program Map Table 
(PMT) information in the MPEG compatible transport stream input to decoder 
100. In addition, the data partitioning, data formatting and data repetition 
frequency characteristics of the CIT and SLD program map information may 
be determined independently of the requirements of MPEG PMT information. 

(Ozkan, Col. 7, lines 37-58)(emphasis added). Thus, rather than introducing PIDs as 
suggested by the Examiner in the alleged second motivation, Ozkan makes no modifications 
to PIDs, but instead develops a new tuning (SLD) table to be used in place of a PMT in a 
digital tuner. As such, although Ozkan is certainly focused on improving tuning in a digital 
television system, it has absolutely no teaching on how to improve the audience measurement 
system of Houston. In short, Houston and Ozkan are just two ships passing in the night. 
While they both are afloat in the digital television space, Ozkan has no reasonable bearing on 
the Houston measurement system. 

Importantly, the Ozkan system makes no mention of timestamping PIDs. As such, 
even were one to employ Ozkan's tuning approach in the digital television system monitored 
by Houston, one would not arrive at a system including a software agent that stores at least a 
portion of the PID header in association with a timestamp as recited in claim 13. 
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The Third False Motivation 

The Examiner alleges: 

The third motivation refers to KSR, where a claimed improvement on 
a device or apparatus is no more than "the simple substitution of one known 
element for another or the mere application of a known technique to a piece of 
prior art ready for improvement," the claim is unpatentable. Accordingly, 
Applicant claims a combination that only unites old elements with no change 
in the respective functions in those old elements and the combination of those 
elements yields predicable results; absent evidence that the modification 
necessary to effect the combination of elements is uniquely challenging or 
difficult for one of ordinary skill in the art, the claim is unpatenable. 

(Office action dates September 17, 2009, Page 9). This third alleged motivation does not fit 

the facts at hand. First of all, no art of record teaches or suggests timestamping PIDs. 

Therefore, timestamped PIDs have NOT been shown to be a known element. Accordingly, it 

is quite impossible for claim 13 to present a situation involving the "simple substitution of 

one known element for another." Similarly, it has been convincingly shown that neither 

Houston nor Ozkan teaches timestamping of PIDs. As such, claim 13 does not present a 

situation of the "mere application of a known technique to a piece of prior art ready for 

improvement." Furthermore, there has been no showing that Houston is "ready for 

improvement," or that Applicant claims a combination that only unites old elements with no 

change in the respective functions in those old elements and the combination of those 

elements yields predicable results." However, this too is completely false. As noted above, 

neither Houston nor Ozkan in anyway contemplate timestamped PIDs or in any way indicate 

that such PIDs can be given a new function for audience measurement. As such, claim 13 is 

NOT merely uniting old elements with no change in the respective functions in those old 

elements as incorrectly alleged by the third motivation. Furthermore, the combination of 

claim 13 yields unpredictable results. As noted above, PIDs are intended to enable a tuner to 
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distinguish between multiplexed program streams received at a given moment in time, but do 
not themselves distinguish between programs from time to time or across major channels. 
As such, at the time of the invention, it was far from predictable that timestamping PIDs 
would have an advantage in an audience measurement application such as the Houston 
system which seeks to universally identify programs across multiple channels to provide 
useful and reliable exposure data and/or ratings. Indeed, the best evidence of this lack of 
predictability is the testimony of Mr. Houston himself who indicated that, while the methods 
and apparatus he disclosed "can be used to collect virtually any type of media measurement 
data," his patent nevertheless does not suggest any need to timestamp PIDs. (132 Declaration 
of John Houston, Paragraph 5). In the words of Mr. Houston, "my patent does not ...in 
anyway indicate that collecting and/or timestamping such PID headers would be of 
interest." (Id.X emphasis added). Therefore, while the Office has provided NO evidence of 
predictability, the Applicants have provided the testimony of the inventor of the primary 
reference relied upon in the rejection demonstrating that, despite the comprehensive nature of 
that prior art reference, it still did not predict any use or value to timestamping PIDs as 
recited in claim 13. Therefore, not only is the third alleged motivation based on false 
assumptions, it is unsupported by any credible evidence. 

As demonstrated above, the rejection of claim 13 is based on multiple errors. In 
particular, the rejection of claim 13 must be withdrawn because: 

(1) the Houston/Ozkan combination results in at least one missing element; and/or 

(2) the three alleged motivations to combine Houston and Ozkan are based on factual 

errors, are inconsistent with the issues presented by claim 13, are unsupported by any 

credible evidence, and are refuted by evidence of record. 
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Accordingly, the rejections of claim 13 and all claims depending therefrom must be 
reversed. 

B. The Art Does Not Teach Timestamping PIDs As Recited In Claim 61 

Claim 61 recites a tangible computer-readable storage medium including a set of 
instructions which, when executed by a computer, provide a software agent stored in 
memory associated with digital television equipment, wherein the software agent is arranged 
to acquire television audience measurement data relative to the digital television equipment, 
the software agent comprising first instructions to store and timestamp at least a portion of 
a television program identification (PID) header from a data packet containing a portion of 
a tuned television program to identify the television program selected for viewing on the 
digital television equipment. The Office action rejects claim 61 on the same art and similar 
reasoning as it rejected claim 13. (See Office action dated September 17, 2009, Pages 13- 
14). In particular, the Office action relies on the Houston/Ozkan combination and the first 
two of the three alleged motivations applied in rejecting claim 13. (Id) As discussed in detail 
above, neither Houston nor Ozkan teach or suggest storing and timestamping PIDs. 
Accordingly, the Houston/Ozkan combination does not result in first instructions to store and 
timestamp at least a portion of a television program identification (PID) header as recited in 
claim 61. Further, as demonstrated above, the alleged motivations to combine Houston and 
Ozkan are based on factual errors, inconsistent with the issues presented by claim 61, 
unsupported by any credible evidence, and refuted by evidence of record. Accordingly, the 
rejections of claim 61 and all claims depending therefrom must be reversed. 



C. The Art Does Not Teach Timestamping PIDs As Recited In Claim 79 
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Claim 79 recites a method implemented by a software agent stored in memory 
associated with digital television equipment, wherein the software agent is arranged to 
acquire television audience measurement data relative to the digital television equipment, the 
method comprising: storing and time stamping at least a portion of a television program 
identification (PID) header from a data packet containing a portion of a tuned television 
program to identify the television program selected for viewing on the digital television 
equipment. The Office action rejects claim 79 on the same grounds as claim 61. (See Office 
action dated September 17, 2009, Page 15). As discussed in detail above, the grounds for 
rejecting claim 61 are in error. Accordingly, for at least the same reasons the rejections of 
claim 61 and all claims depending therefrom must be reversed, the rejections of claim 79 and 
all claims depending from claim 79 must likewise be reversed. 

Ground 2. Claims 62-69, 80-87, 94 and 102 are 

patentable over the Houston/Welsh/Saito combination 

A. Houston/Welsh/Saito is missing at least one element of Claim 62 

Independent claim 62 recites an apparatus for identifying a viewer selected television 
program received by digital television program reception equipment, wherein the digital 
television program reception equipment has a data port to export tuned data. The apparatus 
of claim 62 specifically comprises a reader connected to the data port to read program 
identifying data tuned by the digital television program reception equipment from among 
data exported from the digital television program reception equipment via the data port for 
use by a media device different from the digital television program reception equipment. 
Thus, the plain language of claim 62 identifies three devices, namely, (1) the digital 
television program reception equipment, (2) the reader, and (3) a media device different from 
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the digital television program reception equipment. Further, claim 62 points out that the 

reader is "connected to the data port" of the digital television program reception equipment. 

Significantly, claim 62 requires the reader to read program identifying data from among data 

exported via the data port. Importantly, the data exported via the data port is intended for use 

"by a media device different from the digital television program reception equipment." Thus, 

the plain and clear meaning of claim 62 is that the reader reads (i.e., intercepts or eavesdrops 

on) data exported from the digital television program reception equipment to a media device 

different from the digital television program reception equipment. 

The Final Office action rejected independent claim 62 as unpatentable over Houston, 

in view of Welsh, U.S. Patent 5,374,951, and further in view of Saito, U.S. Patent 6,751,221. 

The Final Office action sums up the rejection as follows: 

The rejection used is Houston teaching a viewer history record storing, 
which is combined with Welsh to teach a slave unit for storing a viewer 
history record being connected by a wire, which is then combined with Saito 
to teach where the wire could be a firewire cord. 

(Office action dates September 17, 2009, Page 7). It is immediately clear from the 
Examiner's summation of his rejection that the Houston/Welsh/Saito combination involves 
only two devices, namely, the master (Houston) device and the slave (Welsh) device. Saito is 
provided merely to make the connection between these two devices a firewire connection. 
Thus, it is likewise immediately clear that the master/slave system of the 
Houston/Welsh/Saito combination does not meet the recitations of claim 62. 

For example, claim 62 recites three devices, not two . Presumably, the Examiner 
intends the Houston (master) device to be analogous to the digital television program 
reception equipment of claim 62, and the Welsh (slave) device to be analogous to the reader 
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of claim 62. However, even in this reading, the Welsh (slave) device would not read program 

identifying data from among data exported from the digital television program reception 

equipment via the data port for use by a media device different from the digital television 

program reception equipment as required by claim 62. In other words, there is no 

reasonable way to read the Welsh slave device as a device that reads data from data intended 

for use by a media device different from the digital television program reception equipment. 

Quite simply, Welsh does not in any way contemplate intercepting data communicated 

between two other devices as required in claim 62. Saito does not change this fact, but 

instead is only relied upon to indicate the master/slave communication between Houston and 

Welsh could be IEEE 1394 protocol communications. Therefore, the Houston/Welsh/Saito 

combination fails to meet at least one recitation of claim 62. For example, the 

Houston/Welsh/Saito combination does not teach or suggest a reader connected to the data 

port to read program identifying data tuned by the digital television program reception 

equipment from among data exported from the digital television program reception 

equipment via the data port for use by a media device different from the digital television 

program reception equipment. Accordingly, the rejections of claim 62 and all claims 

depending therefrom are based on reversible error. 

Furthermore, it flatly makes no sense to attempt to convert Houston into a system 

such as claim 62. As explained by Mr. Houston himself: 

4. The cooperative media handler methods disclosed in my 
patent provide access to a rich amount of audience 
measurement data, so there is nothing to be gained by 
employing eavesdropping methods such as those disclosed in 
the 4 224 application [i.e., the application on appeal] when my 
disclosed methods are available. Therefore, in my opinion, a 
person of ordinary skill in the art reading my patent in the 
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relevant time frame would not be led by my disclosure to the 
invention recited in claims 62 and 80 of the 4 224 application as 
currently presented in the response to the Office action of 
August 1, 2007 filed herewith. Quite simply y the techniques I 
disclose and the techniques recited in claims 62 and 80 relate 
to fundamentally different approaches to media 
measurement. Since my patent has no need of eavesdropping 
techniques such as those recited in claims 62 and 80> in my 
opinion, no person of ordinary skill in the art reading my 
patent would take it as suggesting the eavesdropping 
techniques of the '224 application. 

(Houston Declaration, Paragraph 4) (emphasis added). 

The Office action proposes a master/slave device configuration based on Houston and 
Welsh and further contends that the communications between Houston and Welsh could be 
done in accordance with the IEEE 1394 firewire protocol. However, using the firewire 
protocol for upstream communication might result in exporting the data collected within the 
monitored device by the Houston cooperative media handler, but it provides no rationale for 
completely changing the data collection mechanism of Houston from a software agent 
internal to a monitored media presentation device to a reader that eavesdrops on 
communications to a second media device to collect program identification tags output via 
the firewire port of the monitored media presentation device. In other words, the motivation 
proposed by the Office action might lead one to forward the data collected internally by the 
Houston software agent upstream to the central data collection center, but it would not lead 
one to replace the inventive Houston data collection mechanism with an external reader to 
intercept data for a second media device as recited in claim 62. 

In short, it is clear that none of Welsh, Houston or Saito contemplate using a reader 
coupled to an IEEE 1394 data port to eavesdrop to collect program identification tags from 
data communicated to a second media device. Indeed, given Houston's access to detailed 
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audience measurement information within the monitored equipment via the cooperative 
media handler, there is no need for a reader coupled to an IEEE 1394 port of the monitored 
equipment to record identifier tags exported via the IEEE 1394 port of the monitored 
equipment. Therefore, the only reason anyone would read the Houston/Welsh/Saito 
combination as teaching such an external reader is with a priori knowledge of the invention 
of claim 62. Of course, such hindsight usage of the teachings of the Applicants' invention is 
not a proper basis for rejecting the Applicants' claims. Accordingly, the rejections of claim 
62 and all claims depending therefrom must be reversed. 

B. Houston/Welsh/Saito is missing at least one element of Claim 80 

Independent claim 80 recites a method for identifying a viewer selected television 
program from among a plurality of time overlapped television programs broadcast in a 
viewer selected broadcast channel and received by digital television program reception 
equipment, wherein the digital television program reception equipment has a data port to 
export tuned data to a second media device, the method comprising intercepting program 
identifying data tuned by the digital television program reception equipment from among 
data exported from the digital television program reception equipment via the data port, 
wherein the data port operates in accordance with the IEEE 1394 protocol, the program 
identifying data includes identifier tags exported with the data in accordance with the IEEE 
1394 protocol, and the program identifying data is exported to the second media device. 
Thus, the plain language of claim 80 requires interception of data exported from digital 
television program reception equipment to a second media device. The Final Office action 
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appears to have completely ignored this plain language in rejecting claim 80 based on 

Houston/Welsh/Saito. In particular, the Final Office action states: 

The applicant cited [sic, citing] the Houston Declaration states that as 
the Houston patent does not mention eavesdropping, that it can't be used in 
combination to reject the limitation. As the claims only refer to connecting 
up an external reader and not eavesdropping, this argument is moot. 

(Office action dates September 17, 2009, Page 6)(emphasis added). However, there is no 
apparent difference between "intercepting" a communication and "eavesdropping" on a 
communication. Therefore, it is plain that the Examiner has committed reversible error by 
ignoring the plain language of claim 80. 

As discussed above in connection with claim 62, the Houston/Welsh/Saito 
combination does not teach or suggest intercepting program identifying data from among 
data exported from digital television program reception equipment to a second media device. 
Nor, given the testimony of Mr. Houston and the teachings of the Houston patent itself, is 
there any credible reason to believe it would have been obvious to replace the inventive 
Houston data collection mechanism internal to a media device with an external reader to 
intercept data for a second media device as recited in claim 80. Accordingly, the rejections of 
claim 80 and all claims depending therefrom, must be reversed. 
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In view of the foregoing remarks, it is respectfully submitted that all of the rejections 
made in the final Office action are fatally flawed and must be overturned. 

Respectfully submitted, 

HANLEY, FLIGHT & ZIMMERMAN, LLC. 
Suite 2100 

150 South Wacker Drive 
Chicago, Illinois 60606 
(312) 580-1020 

/James A Flight/ 
James A Flight 
Registration No. 37,622 



By: 

October 18, 2010 
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VIII. Claims Appendix 

1-12. (Cancelled) 

13. A television audience measurement system for digital television equipment, 
wherein the digital television equipment is disposed in a statistically selected location, the 
television audience measurement system comprising: 

a software agent adapted to read a program identification (PID) header from a data 
packet containing a portion of a tuned digital television program to identify the television 
program tuned by the digital television equipment, wherein the software agent is stored in 
memory associated with the digital television equipment and the PID header is broadcast with 
the data packet to enable the digital equipment to tune to a selected one of a plurality of 
minor channels broadcast in a major channel, wherein the software agent stores at least a 
portion of the PID header in association with a timestamp; and 

a communication apparatus adapted to transmit at least one of the at least the portion 
of the PID header and media identification information obtained via the PID header to a 
remotely located central office. 

14. The television audience measurement system of claim 13 wherein the digital 
television equipment comprises a receiver having a tuner, a microprocessor, memory, an 
operating system, and a video display unit. 
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15. The television audience measurement system of claim 13 wherein the digital 
television equipment is a set top box providing an analog television signal to an analog 
receiver. 

16. The television audience measurement system of claim 13 wherein the digital 
television equipment comprises a set top box providing a digital television signal to a digital 
receiver. 

17. The television audience measurement system of claim 13 wherein the digital 
television equipment comprises a set top box and a monitor. 

18. The television audience measurement system of claim 13 wherein the digital 
television equipment comprises a personal computer provided with a television receiver. 

19. The television audience measurement system of claim 13 wherein the digital 
television equipment includes a VCR. 

20. The television audience measurement system of claim 13 wherein the digital 
television equipment includes a digital versatile disk player. 

21. The television audience measurement system of claim 13 further comprising a 
person identification apparatus. 
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22-27. (Cancelled) 

28. The television audience measurement system of claim 13 wherein the software 
agent is arranged to detect window activities conducted by an audience. 

29. The television audience measurement system of claim 13 wherein the 
communication apparatus includes a serial port. 

30. The television audience measurement system of claim 13 wherein the 
communication apparatus includes a parallel port. 

31. The television audience measurement system of claim 13 wherein the 
communication apparatus includes a universal serial bus. 

32. The television audience measurement system of claim 13 wherein the 
communication apparatus includes a fire wire port. 

33. The television audience measurement system of claim 13 wherein the 
communication apparatus is arranged to send the PID header to an Internet service provider 
via the Internet. 

34. The television audience measurement system of claim 13 wherein the 

communication apparatus includes an intermediate data collector. 
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35. The television audience measurement system of claim 34 wherein the 
intermediate data collector includes a store and forward device, and wherein the store and 
forward device is arranged to send the PID header to the central office via a telephone line. 

36. The television audience measurement system of claim 34 wherein the 
intermediate data collector is an Internet service provider. 

37. The television audience measurement system of claim 34 wherein the 
intermediate data collector is a data collection facility located in the central office. 

38. The television audience measurement system of claim 13 wherein the software 
agent is a software agent downloaded to the memory associated with the digital television 
equipment. 

39. The television audience measurement system of claim 13 wherein the software 
agent is a plug in software agent of the digital television equipment. 

40-60. (Cancelled) 

61. A tangible computer-readable storage medium including a set of instructions 

which, when executed by a computer, provide a software agent stored in memory associated 

with digital television equipment, wherein the software agent is arranged to acquire television 
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audience measurement data relative to the digital television equipment, the software agent 
comprising: 

first instructions to store and timestamp at least a portion of a television program 
identification (PID) header from a data packet containing a portion of a tuned television 
program to identify the television program selected for viewing on the digital television 
equipment; 

second instructions to log a co-transmitted datum transmitted in a same major channel 
as the television program selected for viewing on the digital television equipment, the co- 
transmitted datum being related to the tuned television program; and, 

third instructions to log an Internet identification datum associated with an Internet 
task of the digital television equipment. 

62. An apparatus for identifying a viewer selected television program from among 
a plurality of time overlapped television programs broadcast in a viewer selected broadcast 
channel and received by digital television program reception equipment, wherein the digital 
television program reception equipment has a data port to export tuned data, the apparatus 
comprising: 

a reader connected to the data port to read program identifying data tuned by the 

digital television program reception equipment from among data exported from the digital 

television program reception equipment via the data port for use by a media device different 

from the digital television program reception equipment, wherein the data port operates in 

accordance with the IEEE 1394 protocol and the program identifying data read by the reader 

are identifier tags exported with the data in accordance with the IEEE 1394 protocol; and, 
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a memory to store the program identifying data. 

63. The apparatus of claim 62 wherein the digital television program reception 
equipment is a digital converter. 

64. The apparatus of claim 62 wherein the digital television program reception 
equipment is a personal computer. 

65. The apparatus of claim 62 wherein the digital television program reception 
equipment is a digital television set. 

66. The apparatus of claim 62, further comprising a communication device to 
transfer the program identifying data to a remote point. 

67. The apparatus of claim 66 wherein the digital television program reception 
equipment is a digital converter. 

68. The apparatus of claim 66 wherein the digital television program reception 
equipment is a personal computer. 

69. The apparatus of claim 66 wherein the digital television program reception 
equipment is a digital television set. 
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70-78. (Cancelled) 

79. A method implemented by a software agent stored in memory associated with 
digital television equipment, wherein the software agent is arranged to acquire television 
audience measurement data relative to the digital television equipment, the method 
comprising: 

storing and time stamping at least a portion of a television program identification 
(PID) header from a data packet containing a portion of a tuned television program to identify 
the television program selected for viewing on the digital television equipment; 

logging a co-transmitted datum transmitted in a same major channel as the television 
program selected for viewing on the digital television equipment, the co-transmitted datum 
being related to the tuned television program; and, 

logging an Internet identification datum associated with an Internet task of the digital 
television equipment. 

80. A method for identifying a viewer selected television program from among a 
plurality of time overlapped television programs broadcast in a viewer selected broadcast 
channel and received by digital television program reception equipment, wherein the digital 
television program reception equipment has a data port to export tuned data to a second 
media device, the method comprising: 

intercepting program identifying data tuned by the digital television program 

reception equipment from among data exported from the digital television program reception 

equipment via the data port, wherein the data port operates in accordance with the IEEE 1394 
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protocol, the program identifying data includes identifier tags exported with the data in 
accordance with the IEEE 1394 protocol, and the program identifying data is exported to the 
second media device; and, 

storing the program identifying data. 

81. The method of claim 80 wherein the digital television program reception 
equipment is a digital converter. 

82. The method of claim 80 wherein the digital television program reception 
equipment is a personal computer. 

83. The method of claim 80 wherein the digital television program reception 
equipment is a digital television set. 

84. The method of claim 80, further comprising communicating the program 
identifying data to a remote point. 

85. The method of claim 84 wherein the digital television program reception 
equipment is a digital converter. 

86. The method of claim 84 wherein the digital television program reception 
equipment is a personal computer. 
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87. The method of claim 84 wherein the digital television program reception 
equipment is a digital television set. 

88. The television audience measurement system of claim 13 wherein the 
communication apparatus transmits the time stamps to the remotely located central office to 
facilitate compilation of audience measurement data. 

89. The television audience measurement system of claim 13 wherein the 
communication apparatus is an output port of the digital television equipment. 

90. The television audience measurement system of claim 89 wherein the output 
port outputs data in accordance with the IEEE 1394 protocol. 

91. (Cancelled) 

92. The software agent of claim 61 wherein the digital television equipment 
includes an output port to export at least one of the time stamped PID header, the co- 
transmitted datum, or the Internet identification datum. 

93. The software agent of claim 92 wherein the output port outputs data in 
accordance with the IEEE 1394 protocol. 



39 



US Application 09/909,224 
Brief on Appeal 

94. The apparatus of claim 62 wherein the reader time stamps the program 
identifying data. 



95. (Cancelled) 



96. (Cancelled) 



97. (Cancelled) 



98. (Cancelled) 



99. The method of claim 79 further comprising exporting at least one of the time 
stamped PID header, the co-transmitted datum, or the Internet identification datum from the 
digital television equipment via an output port operating in accordance with the IEEE 1394 
protocol. 



100. The method of claim 80 further comprising time stamping the program 
identifying data. 



101. (Cancelled) 



102. The method of claim 84 further comprising time stamping the program 
identifying data. 
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(Cancelled) 
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IX. Evidence Appendix 

The evidence relied upon is reflected in the following table. 



Reference 


Entered in Record 


Houston, US Patent 6,353,929 


Relied upon to reject the claims on 
appeal in the Final Office Action. 
Entered in the record by the Examiner 
on PTO-892 dated October 19, 2005. 


Ozkan, US Patent 6,031,577 


Relied upon by the Examiner to reject 
the claims on appeal in the Final Office 
Action. Entered in the record by the 
Examiner on PTO-892 dated June 15, 
2006. 


Welsh, US Patent 5,374,951 


Relied upon to reject the claims on 
appeal in the Final Office Action. 
Entered in the record by the Examiner 
on PTO-892 dated February 6, 2009. 


Saito, US Patent 6,751,221 


Relied upon to reject the claims on 
appeal in the Final Office Action. 
Entered in the record by the Examiner 
on PTO-892 dated June 15, 2006. 
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132 Declaration of Houston 
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3, 2007 discussed by the Examiner in 




non-final rejection mailed February 6, 




2009. 
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ABSTRACT 



A cooperative electronic media measurement system is 
disclosed which uses media handlers to obtain information 
from, or otherwise obtain information about, presented 
media objects, including identification tags, if present, for 
collection by research data collection agents and subsequent 
dispatch to a centralized media research controller. The 
media research controller registers advertisements and other 
media for subsequent measurement and provides a unique 
identification tag that may be added to, or associated with, 
the existing media object. Media objects are presented to a 
panel member by a panel member-computing device which 
may receive media objects by means of a network 
connection, from one or more local sources, or generate 
media objects in real-time, or a combination thereof. One or 
more research data collection agents are assigned to measure 
each panel member's exposure to and interactions with 
electronic media. Cooperative media handlers automatically 
obtain information from, or otherwise obtain information 
about, presented media objects including identification tags, 
if present, and other information, for collection by the 
research data collection agents. A research data collection 
agent will track a panel member, and collect such transmis- 
sions from the cooperative media handlers, when a panel 
member is in the scope of the research data collection agent. 
The research data collection agent (i) creates log entry 
objects from transmissions received from the cooperative 
media handlers and places the log entry objects into an 
unfiltered media queue, (ii) confirms the integrity of the 
messages and filters out unnecessary log entry objects from 
the unfiltered media queue to create a filtered media queue, 
(iii) creates dispatch objects using objects from the filtered 
media queue and places created dispatch objects into a 
dispatch queue, and (iv) transmits dispatch objects from the 
dispatch queue to the media research controller, when 
resources are available. 
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COOPERATIVE SYSTEM FOR MEASURING 
ELECTRONIC MEDIA 

FIELD OF THE INVENTION 

The present invention relates generally to a system for 
measuring a population's exposure to and interactions with 
electronic media (hereinafter, "electronic media measure- 
ment systems"), and more particularly, to a cooperative 
electronic media measurement system using media handlers 
to extract information from, or otherwise obtain information 
about, presented media objects, including identification tags, 
if present, for collection by software agents on behalf of a 
centralized media research facility. 

BACKGROUND OF THE INVENTION 

The success of any advertising campaign depends on the 
accurate placement of advertisements within media, and the 
verification that specific advertising messages were pre- 
sented in accord with a predefined media plan. Generally, an 
advertising campaign is targeted for one or more segments 
of a population, with media planners determining the best 
media a vehicles to reach the target audience. In this manner, 
the advertiser seeks to find the most efficient media to 
minimize the cost to deliver a desired audience. 

Thus, prior to executing a given advertising campaign, 
media planners use syndicated research, such as Nielsen 
ratings, to determine the best media vehicles to reach a target 
audience. In addition, media planners utilize other informa- 
tion sources to research and compare the costs associated 
with reaching an audience through each available media 
vehicle. During a given advertising campaign, it is helpful to 
measure the target audience's exposure to the advertising 
messages, since media planners might make corrections in 
order to optimize the execution of the media plan. Likewise, 
after a given advertising campaign, media planners often 
analyze the execution of the campaign to confirm that the 
advertising messages reached the targeted audience to deter- 
mine the accuracy of the campaign's messages in reaching 
the targeted audience. 

As audiences have fragmented, due to the increasing 
number of available channels and online options, it has 
become increasingly challenging for media planners to 
determine which media vehicles provide the best avenue to 
a given audience. The Internet, in particular, provides adver- 
tisers with many media options and is becoming ubiqui- 
tously available in an expanding variety of personal elec- 
tronic devices, far beyond its initial limited availability to 
users via computer terminals and desktop computers. As 
with other media, advertising has become an important part 
of Internet revenue models. Much of the Internet's value to 
the advertising community is due to its enormous and 
evolving diversity of advertising formats, including the 
banner ad and Java applets, and its capability to deliver 
customized and relevant advertising to end users. For a more 
detailed discussion of advertising media, see D. Jugenhe- 
imer et al., Advertising Media Strategy and Tactics (W.C.B. 
Brown & Benchmark, 1992), incorporated by reference 
herein. 

Thus, the Internet provides an efficient mechanism for 
matching the advertising message to the appropriate seg- 
ment of the audience. Such diverse advertising formats, 
however, present challenges for measuring a population's 
exposure to and interactions with such advertisements. 
While the success of the Internet can be attributed, in large 
part, to its open media standards that permit the creation and 
delivery of content having diverse formats across many 



i3,929 Bl 

2 

platforms, there is currently no user-centric system capable 
of adequately measuring the diverse media formats across 
the growing variety of Internet-enabled consumer platforms, 
consistent with the needs of the advertising community. 

5 Generally, a given population's exposure to and interac- 
tions with media is measured by knowing the television 
channels and other information sources that the members of 
the population select. This can be performed either as a 
census, where the choices of the entire population are 

10 collected, or as a sample, where a statistically valid sub- 
population or panel is chosen to represent the entire popu- 
lation. Nielsen Media Research, for example, uses a panel of 
households, known as "Nielsen Families," for measuring 
television viewing. Such panels enable research companies 

15 to correlate demographics, such as age, gender, income and 
education, with choice of content. 

Conventional content frequently contains, or is associated 
with, metadata that provides information about the content. 
For example, many broadcasters transmit information with 

20 conventional programming to help identify the content, for 
example, by program and episode. Nielsen, for example, 
extracts such accompanying information for measurement 
purposes to track the programs viewed by certain members 
of a panel. In addition, smart electronic program guides use 

25 such accompanying information to help individuals or their 
agents find content of interest. 

Similarly, the World Wide Web Consortium (W3C), has 
endorsed the Platform for Internet Content Selection (PICS), 

30 which is an open standard for tagging information and 
coding content on the Internet. The PICS standard is 
designed to allow software to automatically filter content 
that individuals choose not to receive, such as violent 
content, according to a ratings system. The PICS standard 

35 provides parents and other individuals with the ability to 
select categories of content that can be automatically 
blocked, in a similar manner to V-chip technology, for 
conventional programming. While the PICS standard allows 
an entire web site or static pages to be rated, the PICS 

40 standard does not permit tagging content on an object level. 
In addition, traditional electronic advertising, such as 
television and radio advertisements, have unique identifica- 
tion codes, or Industry Standard Commercial Identification 
(IS CI) codes, which are used for handling, broadcasting, 

45 storing and retrieving commercials. Under the ISCI 
standard, an ISCI alpha prefix and an ISCI numeric code 
identify each commercial. An ISCI prefix is assigned by 
ISCI to national and regional advertisers and advertising 
agencies. The ISCI code may be used in any manner, at the 

50 discretion of the prefix owner, provided the code consists of 
four letters followed by four numbers. Although ISCI codes 
are not presently encoded as computer readable data with 
each advertisement, they might evolve to do so for Internet 
advertising, to better manage advertising on the Internet. 

55 There exists both "pull" and "push" models for delivering 
Internet content. On traditional web sites, individuals "pull" 
content by browsing. These web sites can use tools to 
analyze the "hits" to their sites in real-time. Additionally, 
there exist "push" models of content delivery, such as 

60 provided by PointCast™. PointCast™ is a webcasting ser- 
vice that "pushes" or streams a variety of information, 
including editorial and advertising content, to a receiving 
software component, such as their proprietary Screensaver, 
or Microsoft's Internet Explorer browser, version 4.0. 

65 Presently, each PointCast™ subscriber self -reports demo- 
graphic information. Therefore, PointCast™ can provide 
advertisers with user-centric information about advertising 
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exposure. Self -monitoring, however, is contrary to advertis- 
ing industry guidelines, which express a preference for 
measurement by a disinterested third party. In addition, the 
PointCast™ system is limited to measuring only electronic 
media distributed by PointCast™. 5 

Even assuming that an independent auditor verified such 
site-centric measurements, the measurements often do not 
accurately reflect the activity of individuals. For example, 
many of the "hits" on a web site are associated with 
electronic agents that perform functions on the Internet on 10 
behalf of individuals. Examples of such electronic agents 
include web robots, issued by search engines such as those 
provided by Infoseek Corp. to index the contents of the 
Internet, and personal agents that automatically retrieve 
information from the Internet that matches the specified 1 5 
preferences of an individual. Thus, such electronic agents 
increase the traffic count of the respective web site, as they 
are not necessarily representative of an individual viewing 
Internet content. For example, an agent might download the 
entire contents of a site, while the user only views a single 2 o 
article. Proxy servers, on the other hand, which cache or 
copy Internet content to a local server or hard disk drive for 
subsequent access, can decrease the traffic count of a given 
web site. Proxy servers are used to reduce access time by 
storing a copy of information that was recently downloaded 2 5 
from a site. Thus, upon a subsequent request, the informa- 
tion can be delivered from the local server rather than the 
Internet without the knowledge of the web site traffic 
counter. 

While conventional electronic media measurement 30 
systems, such as Nielsen Media Research's PeopleMeter™, 
have successfully measured traditional media, such as tele- 
vision and radio, such systems are not easily extendable to 
the Internet environment. In addition, the site -centric mea- 
surement approaches discussed above have proven unsatis- 35 
factory. In order to accurately measure a population's expo- 
sure to and interactions with such electronic media, a 
user-centric measurement approach is needed which is based 
on a panel chosen to be statistically representative of the 
total population of interest. Current user-centric Internet 40 
measurement systems, however, such as the NPD Group's 
PC Meter™, are based on interception and interpretation of 
electronic media presented to members of a panel. Such 
interception techniques, however, rely on observing calls by 
software applications to the operating system and require 45 
privileged access into operating system internals. 
Furthermore, PC Meter™ is currently limited to household 
users of the Windows™ operating system, which may not be 
statistically representative of the total population of interest. 
For a more detailed discussion of the PC Meter™ system, 50 
see PCT Published Application Number WO 96/41495. 

It is believed that observing operating system internals 
will become increasingly challenging, if not impossible, 
with the trend towards more secure operating systems and 
communication security. Windows NT™ from Microsoft™, 55 
for example, implements a concentric ring structure of 
ascending privilege with an outermost ring of lowest privi- 
lege and an innermost ring of highest privilege, from which 
applications are excluded, based on the processor ring 
architecture specified by Intel Corporation. As security ser- 60 
vices become more available to Internet applications, both 
for computer-to -computer communications and application- 
to- application communications, much of this internal traffic 
will be encrypted. In addition, such operating system moni- 
toring techniques will be challenging to implement within 65 
the many proprietary implementations of Internet-enabled 
devices, such as WebTV™. Even assuming that such user- 
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centric measurement systems are successful in obtaining 
access to these communications, it is very challenging to 
understand what the intercepted messages mean. 

A recent industry article indicates that a new company, 
Relevant Knowledge Inc., of Atlanta, Ga., has developed a 
real-time approach to compete with the PC Meter™ system. 

Although Relevant Knowledge Inc. did not comment 
publicly for the article, it does not appear that Relevant 
Knowledge Inc. is using a cooperative approach. Rather, it 
appears that Relevant Knowledge Inc. is monitoring 
information, using interception and interpretation, and lever- 
aging the communication capabilities of the Internet to 
distribute their monitoring software to their panel members 
and to collect data in real-time. 

As apparent from the above-described deficiencies with 
conventional electronic media measurement systems, a need 
exists for a universal system for measuring electronic media 
having diverse formats, including television, radio, Internet, 
and online services, across a plurality of platforms. A further 
need exists for a cooperating system that extends the open 
media standards of the Internet to measure a population's 
exposure to and interactions with such electronic media. Yet 
another need exists for a system to measure traditional 
television, radio, cable television, digital satellite program- 
ming and advertising delivered to households that use 
Internet-enabled computers and appliances for viewing, 
listening and interacting with such content. 

SUMMARY OF THE INVENTION 

Generally, according to one aspect of the invention, media 
information presented to a panel member by means of a 
panel member-computing device is measured by a media 
research controller for subsequent reporting to one or more 
research customers. The panel member-computing device 
may receive the media information by means of a network 
connection, or from one or more local sources, such as 
prerecorded media obtained from a CD-ROM or DVD 
player, or may generate the media objects in real-time, or a 
combination thereof. The media research controller registers 
advertisements and other media for subsequent measure- 
ment and provides a unique identification tag that may be 
added to, or associated with, the existing media object for 
identification purposes. In addition, the present invention 
extracts information from, or otherwise obtains information 
about, presented media objects, including metadata or other 
information associated with a given media object, for later 
collection by the media research controller even when the 
media object has not been previously registered and tagged 
by the media research controller. Thus, a panel member's 
exposure to and interactions with all electronic media is 
measured, regardless of whether the media has been previ- 
ously registered or tagged for identification purposes. The 
panel members are preferably chosen for their demographics 
and have agreed to participate in a research panel to have 
their electronic media measured. 

The media research controller preferably assigns one or 
more software agents, hereinafter referred to as research data 
collection (RDC) agents, to measure each panel member's 
exposure to and interactions with electronic media. Thus, 
each research data collection agent serves as an intermediary 
between the local environment of a panel member and the 
central media research controller. In one embodiment, a 
research data collection agent is associated with each com- 
puting device utilized by a given panel member. Thus, a 
single panel member might be assigned multiple research 
data collection agents, if required, to measure the panel 
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member's use of electronic media across multiple devices. 
Furthermore, a single research data collection agent may 
serve a plurality of panel members utilizing the same 
computing device. 

According to a further aspect of the invention, coopera- 5 
tive media handlers are utilized by the panel member- 
computing device to present media to a panel member and 
to extract information from, or otherwise obtain information 
about, the media objects, including identification tags, if 
present, for collection by the research data collection agents. 10 
As used herein, the term cooperating system means a system 
that relies on the media handler software which presents the 
media to cooperate by gathering and developing information 
about media activities of end users, and transmitting such 
activity information to the media research controller, either 15 
directly or indirectly via the research data collection agents, 
in effect acting as agents of the media research controller, as 
opposed to conventional approaches of intercepting and 
interpreting the media activities of end users. 

As used herein, the term media handler includes persistent 2 o 
software components which extend the capabilities of a 
software application or operating system to present media 
objects of a particular media type to an individual and 
autonomous software components, such as Java applets, 
which may only temporarily extend the capabilities of the 2 5 
host to present media. In addition, the term media handler 
includes software applications that generate media experi- 
ences in real-time, such as video games, and resident soft- 
ware components, such as the PointCast™ agent, which 
present media to end users. In addition, the term media 30 
handler includes those portions of an Internet browser, also 
called "viewers" and "plug-ins", that are capable and 
responsible for decoding specific media types, such as JPEG 
images, and using the resources of their host to present the 
media to the end user. The media handlers may be mobile, 35 
moving from one host computer to another, or stable, 
anchored to one host. 

Thus, in addition to their primary function of presenting 
media, the cooperative media handlers also serve as software 
agents for the research data collection agents, by gathering 40 
and deriving relevant information about the media presen- 
tation on behalf of the research data collection agents and 
then sending this information to the research data collection 
agents. The media handlers are in the best position to 
provide information about the media objects presented to the 45 
panel members, since the media handler can decode the 
particular media type, and determine what is presented to the 
individual, when it is presented and how the individual 
interacts with the object. In this manner, the media handler 
can report on a panel member's exposure to and interactions 50 
with a media object, such as zooming in on a particular 
feature of a media object or rotating the object, and the 
source of the control signals, such as a specific individual or 
process. In the case of stable, installed media handlers, such 
as video games or Screensaver clients; or in the case of 55 
mobile, transient media handlers, such as a Java applet 
advertisement, they become cooperative through the imple- 
mentation of an application programming interface (API), 
and communicate to the research data collection agents via 
their host. In all of these instances, the media handler's host 60 
might contribute contextual information, such as the web 
site of origin, to the media handler along with the media 
object. 

The hosts of the research data collection agent and the 
cooperative media handlers preferably provide them with 65 
necessary computational resources, such as processor 
cycles, memory and communication. In the illustrative 



929 Bl 

6 

embodiment, an Internet browser software product, such as 
Netscape Navigator™ or Microsoft Internet Explorer™, 
resident on the panel member-computing device, serves as 
the host for both the research data collection agent and the 
cooperative media handler. In alternate embodiments, the 
host for one or both of the research data collection agent and 
the cooperative media handlers may be embodied as an 
operating system or a virtual machine, such as the Java 
virtual machine. The research data collection agents and the 
cooperative media handlers (the hosted processes) prefer- 
ably use an application programming interface (API) to 
define the function calls which the hosted processes and 
their hosts use to communicate and share resources and 
services. In this manner, different companies can develop 
interoperable research data collection agents, cooperative 
media handlers and hosts. 

When electronic media is received by a cooperative media 
handler, the media handler automatically extracts informa- 
tion from, or otherwise obtains information about, the 
media, including an identification tag, if present, for trans- 
mission to a research data collection agent. In addition to the 
extracted identification tag, if present, the cooperative media 
handler preferably transmits any content metadata included 
in or associated with the media object, an indication of the 
media handler's identification number and any contextual 
information which has been made available to the media 
handler by its host, including program, episode, version, and 
source information for television and radio programming, or 
a source computer's domain name or IP address for a web 
site, and content rating information, such as PICS, if avail- 
able. 

A research data collection agent preferably commences 
tracking of a panel member, and begins collecting such 
transmissions from the cooperative media handlers, when a 
panel member enters the scope of the research data collec- 
tion agent and has been identified and authenticated, for 
example, following a log on procedure. Similarly, the 
research data collection agent suspends tracking of a panel 
member when the person leaves the scope of the remote 
media research agent, such as following a log off procedure. 
The research data collection agent (i) creates log entry 
objects from transmissions received from the cooperative 
media handlers and places the log entry objects into an 
unfiltered media queue, (ii) confirms the integrity of the 
messages and filters out unnecessary log entry objects from 
the unfiltered media queue to create a filtered media queue, 
(iii) creates dispatch objects using objects from the filtered 
media queue and places created dispatch objects into a 
dispatch queue, and (iv) transmits dispatch objects from the 
dispatch queue to the media research controller, when 
resources are available. 

Identification tags are preferably placed at periodic inter- 
vals throughout the duration of continuous media, such as 
audio and video, or on an associated data channel. Since 
identification tags might be utilized by hostile software to 
automatically remove advertising media objects, the identi- 
fication tags are preferably placed in both the advertising, as 
well as the associated advertising-supported media objects 
to discourage such automatic removal. In one preferred 
embodiment, "real" identification tags are placed in media 
that is to be measured (and a fraction of media that is not to 
be measured), and "dummy" identification tags are placed in 
other content. The research data collection agents can pref- 
erably distinguish real identification tags from dummy iden- 
tification tags, and, if desired for efficiency purposes, can 
only return measurements about registered media objects 
containing real identification tags to the media research 
controller. 
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A more complete understanding of the present invention, 
as well as further features and advantages of the present 
invention, will be obtained by reference to the following 
detailed description and drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 5 

FIG. 1 is a schematic block diagram illustrating a suitable 
communications network for interconnecting a panel mem- 
ber with one or more content providers and a media research 
controller of an electronic media measurement system; io 

FIG. 2 illustrates the communications and cooperative 
relationship between the various entities shown in FIGS. 1, 
3 and 4; 

FIG. 3 is a schematic block diagram of the media research 
controller of FIG. 1; 15 

FIG. 4 is a schematic block diagram of a panel member- 
computing device of FIG. 1; 

FIG. 5 illustrates a sample table from the panel member 
database table of FIG. 2; 

FIG. 6 illustrates a sample table from the registered media 
database table of FIG. 2; 

FIG. 7 illustrates a sample table from the encryption keys 
database table of FIG. 2; 

FIG. 8 illustrates a sample table from the log entry 2 5 
database table of FIG. 2; 

FIG. 9 illustrates a sample table from the local panel 
member database table of FIG. 3; 

FIG. 10 illustrates a sample table from the local encryp- 
tion keys database table of FIG. 3; 30 

FIG. 11 illustrates a sample log entry object from the 
media queues of FIG. 3; 

FIG. 12a is a flow chart describing an exemplary tag 
registration and encoding process as implemented by the 
media research controller of FIG. 3; 35 

FIGS. 12b and 12c illustrate an exemplary identification 
tag format definition for a real identification tag and a 
dummy identification tag, respectively; 

FIG. 13 is a flow chart describing a data importing process 
as implemented by the media research controller of FIG. 3; 40 

FIG. 14 is a flow chart illustrating a reporting process as 
implemented by the media research controller of FIG. 3; 

FIG. 15a provides an overview of the processes shown in 
FIGS. 15b through 15/ on the media queues of FIG. 4; ^ 

FIG. 15b is a flow chart describing a logging process as 
implemented by the research data collection agent of FIG. 4; 

FIG. 15c is a flow chart describing a filter process as 
implemented by the research data collection agent of FIG. 4; 

FIG. 15<i is a flow chart describing a tag decoding 50 
subroutine as implemented by the research data collection 
agent of FIG. 4; 

FIG. 15e is a flow chart describing a ere ate -dispatch 
object process as implemented by the research data collec- 
tion agent of FIG. 4; 55 

FIG. 15/ is a flow chart describing a dispatch process as 
implemented by the research data collection agent of FIG. 4; 

FIG. 16 is a flow chart describing a suitable host tracking 
process as implemented by the panel member-computing 
device of FIG. 4; and 60 

FIG. 17 is a flow chart describing a cooperative media 
handler process as implemented by the panel member- 
computing device of FIG. 4. 

DETAILED DESCRIPTION 65 

FIG. 1 shows an illustrative network environment for 
transferring media information, such as video, audio and 



data, from one or more content providers 110, 120, to a panel 
member 205 operating a panel member-computing device 
400, discussed further below in conjunction with FIG. 4, 
over one or more external networks, such as network 130. In 
an alternative or supplemental embodiment, discussed far- 
ther below, the panel member-computing device 400 may be 
configured to receive media information from one or more 
local sources, such as prerecorded media obtained from a 
CD-ROM or DVD player, or to generate media objects in 
real-time, for example, by means of a video game generating 
an advertising image with the name of the panel member for 
placement on a wall inside a virtual world, or a combination 
thereof. According to a feature of the present invention, the 
media information presented to the panel member by means 
of the panel member-computing device 400 is measured by 
a media research controller 300, discussed further below in 
conjunction with FIG. 3, for subsequent reporting to one or 
more research customers 150. It is noted that the reports may 
be generated by the media research controller 300 in real 
time, or historically, or both. 

The external networks 130 shown in FIG. 1 include the 
Internet, the Public Switched Telephone Network ("PSTN") 
and networks for the delivery of radio and television 
programming, such as the Digital Satellite Service 
("DSS™"), cable television ("CATV") and other over-the- 
air transmission networks for broadcast television, radio and 
satellite communications. The PSTN, as used herein, 
includes the combination of local and long distance wire or 
wireless facilities and switches, as well as cellular network 
systems. The Internet, as used herein, includes the World 
Wide Web (the "Web") and other systems for storing and 
retrieving information using the Internet. 

According to a feature of the present invention, the media 
research controller 300 registers advertisements and other 
media for subsequent measurement and provides a unique 
identification tag that may be added to, or associated with, 
the existing media object for identification purposes. In 
addition, the present invention extracts information from, or 
otherwise obtains information about, presented media 
objects, including metadata or other information associated 
with a given media object, for later collection by the media 
research controller 300 even when the media object has not 
been previously registered and tagged by the media research 
controller 300. In this manner, the present invention mea- 
sures a panel member's exposure to and interactions with all 
electronic media, regardless of whether the media has been 
previously registered or tagged for identification purposes. 
The panel members are preferably chosen for their demo- 
graphics and have agreed to participate in a research panel 
to have their electronic media measured. The panel is 
preferably constructed so that it is representative of and 
projectable to the entire population. It is noted that if a 
census is desired, as opposed to a panel, the panel simply 
consists of the entire population of interest. 

Entity Relationships and Interfaces 

As shown conceptually in FIG. 2, the present invention 
preferably consists of a number of cooperating entities to 
measure electronic media presented to a panel member 205 
by means of the panel member-computing device 400, 
namely, a centralized media research controller 300, a 
research data collection agent 1500 and a cooperative media 
handler 1700. As previously indicated, the media research 
controller 300 measures a panel's exposure to and interac- 
tions with electronic media for subsequent reporting to one 
or more research customers 150. As used herein, the term 
cooperating system means a system that relies on the media 
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handler software which presents the media to cooperate, by 
gathering and developing information about media activities 
of end users and transmitting such activity information to the 
media research controller, either directly or indirectly via the 
research data collection agents, in effect acting as agents of 5 
the media research controller, as opposed to conventional 
approaches of intercepting and interpreting the media activi- 
ties of end users. 

To this end, the media research controller 300 preferably 
assigns one or more software agents, referred to as research 10 
data collection agents 1500, discussed further below in 
conjunction with FIG. 15, to measure each panel member's 
exposure to and interactions with electronic media. Thus, 
each research data collection agent 1500 serves as an inter- 
mediary between the local environment of a panel member 15 
205 and the central media research controller 300. In one 
embodiment, a research data collection agent 1500 is asso- 
ciated with each computing device 400 utilized by a given 
panel member 205. Thus, a single panel member might be 
assigned multiple research data collection agents, if required 20 
to measure the panel member's use of electronic media 
across multiple devices. Furthermore, a single research data 
collection agent 1500 may serve a plurality of panel mem- 
bers utilizing the same computing device 400. It is not 
necessary for the research data collection agent 1500 to be 25 
proximal to the associated panel member or the panel 
member's physical environment. Since the research data 
collection agent 1500 is user-centric, the agent 1500 might 
be a component of the person's net-centric environment and 
be activated as a side effect of the person obtaining access 30 
to network resources, or the agent 1500 may reside on a 
smartcard carried by the individual. 

In addition, the cooperative media handlers 1700, dis- 
cussed below in conjunction with FIG. 17, are utilized by the 
panel member- computing device 400 to present media to the 35 
panel member 205 and to extract information from, or 
otherwise obtain information about, presented media 
objects, including identification tags, if present, for collec- 
tion by the research data collection agents 1500. Thus, in 
addition to their primary function of presenting media, the 40 
cooperative media handlers 1700 also serve as software 
agents for the research data collection agents 1500, by 
gathering and deriving relevant information about the media 
presentation on behalf of the research data collection agents 
and then sending this information to the research data 45 
collection agents. It is noted that while some of the media 
handlers might be implemented as cooperative media han- 
dlers 1700, as described herein, the present invention is not 
dependent upon all of the media handlers being imple- 
mented in a cooperative manner. However, the extent of 50 
research data collection agent's 1500 ability to measure a 
panel member's exposure to and interactions with electronic 
media is limited to media presented by means of a coop- 
erative media handler 1700. 

As used herein, a software agent is a software component 55 
that has the ability and authority to act on behalf of a 
controlling entity, generally instantiated as a process on a 
host computer. Each agent's controlling entity provides the 
agent with resources, such as encryption keys and a digital 
certificate for identification, and delegates specific tasks to 60 
the agent. The software agents manage these tasks, and 
operate in an autonomous or semi-autonomous mode with 
respect to its controlling entity. The software agents may be 
mobile, moving from one host computer to another, or 
stable, anchored at one host. 65 

The software agent's host preferably provides the soft- 
ware agent with necessary computational resources, such as 
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processor cycles, memory and communication. In the illus- 
trative embodiment, discussed further below, an Internet 
browser software product, such as Netscape Navigator™ or 
Microsoft Internet Explorer™, resident on the panel 
member-computing device 400, serves as the host 1600 for 
the research data collection agent 1500 and the host 1600' for 
the cooperative media handler 1700 and provides them with 
the required computational resources. In alternate 
embodiments, the host for one or both of the research data 
collection agent and the cooperative media handlers may be 
embodied as an operating system or a virtual machine, such 
as the Java virtual machine. The research data collection 
agent 1500 preferably communicates with the media 
research controller 300 by means of the host's secure 
communication capabilities, such as SSL or S/MIME. In 
addition, the research data collection agent 1500 relies on its 
host 1600 to pass through data sent by the cooperative media 
handler 1700 for collection by a research data collection 
agent 1500. 

The communications between the various entities are 
preferably sufficiently encrypted to protect the privacy of the 
panel members 205, the proprietary information and com- 
petitive interests of the media research controller 300 and 
the validity of the collected data, as would be apparent to a 
person of ordinary skill. Furthermore, to protect the privacy 
of nonpanel members, the cooperative features of the hosts 
1600, 1600', as described herein, are preferably initially 
disabled when distributed to end-users, and are only subse- 
quently enabled when specifically authorized by a panel 
member who has agreed to participate in a research panel. 

In some embodiments, the research data collection agent 
1500 is not proximal to the panel member(s) it tracks, or the 
panel member's physical environment. For example, the 
research data collection agent might be hosted by the central 
computer of an online service. In other embodiments, the 
research data collection agent is hosted separately from the 
cooperative media handlers. For example, the research data 
collection agent 1500 might be located in a wristwatch worn 
by the panel member. Thus, the host services and resources 
may reside locally or be accessed by means of a network 
connection, or a combination thereof, as would be apparent 
to a person of ordinary skill. It is noted that the research data 
collection agents 1500 and the cooperative media handlers 
1700 might typically share the same host or might be hosted 
separately, for example, in an embodiment where the media 
research data collection agent 1500 associated with a panel 
member 205 is resident on a smartcard or wristwatch carried 
by an individual. 

As illustrated in FIG. 2, the present invention relies on a 
number of cooperative interfaces between the various enti- 
ties. A media object is presented to a panel member 205 by 
the cooperative media handler 1700 using a conventional 
bi-directional user interface 210. The cooperative media 
handler 1700 transmits identification tags and other infor- 
mation extracted from, or otherwise obtained about, media 
objects for collection by a research data collection agent 
1500, by means of a cooperative interface 220. Upon receipt 
of an extracted identification tag or other obtained informa- 
tion from a media handler 1700, the research data collection 
agent 1500 sends a message to the media research controller 
300, preferably over an external network 130, containing the 
extracted identification tag and other obtained information. 

In addition, as previously indicated, the research data 
collection agents 1500 and the cooperative media handlers 
1700 also require interfaces to their respective hosts 1600, 
1600'. In a preferred embodiment, the research data collec- 
tion agents 1500 and the cooperative media handlers 1700 
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(the hosted processes) use an application programming 
interface (API) to define the function calls which the hosted 
processes and their hosts, such as the host 1600, use to 
communicate and share resources and services. In this 
manner, different companies can develop interoperable 5 
research data collection agents, cooperative media handlers 
and hosts. 

Entity Functions 

As previously indicated, when electronic media is 
received by a cooperative media handler 1700, for 10 
presentation, the media handler 1700 automatically extracts 
information from, or otherwise obtains information about, 
presented media object, including an identification tag, if 
present, and other relevant information, as available, for 
transmission to a research data collection agent 1500. In 15 
addition to the extracted identification tag, if present, the 
cooperative media handler 1700 preferably transmits any 
content metadata included in or associated with the media 
object, including program and episode information; an iden- 
tification of media handler and its host; any contextual 2 o 
information which has been made available to the media 
handler 1700, such as an indication of the media source for 
television and radio programming, or a source computer's 
domain name or IP address for a web site; any presentation 
information or user interaction information, and content 2 5 
rating information, such as PICS, if available. Each of these 
information types is discussed further below in conjunction 
with FIG. 8. 

A research data collection agent 1500 preferably com- 
mences tracking of a panel member, and begins collecting 30 
such transmissions from the cooperative media handlers 
1700, when a panel member enters the scope of the research 
data collection agent 1500 and has been identified and 
authenticated, for example, following a log on procedure. 
Similarly, the research data collection agent 1500 suspends 35 
tracking of a panel member 205 when the person leaves the 
scope of the remote media research agent 1500, such as 
following a log off procedure. The research data collection 
agent (i) creates log entry objects from transmissions 
received from the cooperative media handlers and places the 40 
log entry objects into an unfiltered media queue, (ii) con- 
firms the integrity of the messages and filters out unneces- 
sary log entry objects from the unfiltered media queue to 
create a filtered media queue, (hi) creates dispatch objects 
using objects from the filtered media queue and places 45 
created dispatch objects into a dispatch queue, and (iv) 
transmits dispatch objects from the dispatch queue to the 
media research controller, when resources are available. 

The cooperative media handlers 1700 preferably are not 
aware of whether or not a research data collection agent 50 
1500 is present and measuring the content presented to a 
panel member, for the same reason that the identities of 
Nielsen families are carefully concealed from the media 
sources that Nielsen measures, to prevent manipulation of 
the content presented to the panel members. Thus, the 55 
cooperative media handlers 1700 preferably transmit infor- 
mation extracted from, or otherwise obtained about, pre- 
sented media objects, for collection by a research data 
collection agent 1500, whether or not a research data col- 
lection agent 1500 is present. For efficiency purposes, 60 
however, when the same host 1600 is hosting both the 
research data collection agent 1500 and media handler 1700, 
the host may inhibit the cooperative media handler 1700 
from transmitting information extracted from or obtained 
about media objects when a research data collection agent 65 
1500 is not present, is not in a tracking mode or the panel 
members are not in scope. 
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According to a feature of the present invention, the media 
handlers 1700 thus cooperate with the research data collec- 
tion agents 1500 by gathering and deriving relevant infor- 
mation about the media presentation on behalf of the 
research data collection agents and then sending this infor- 
mation to the research data collection agents. The media 
handlers 1700 are in the best position to provide information 
about the media objects presented to the panel members 205, 
since the media handler is responsible for decoding or 
generating specific media objects, they determine what is 
presented, how it is presented, when it is presented and how 
the panel member 205 interacts with the presented media. 
Additionally, the media handlers 1700 can extract metadata 
from the media object and glean contextual information 
about the media object from the media handler's host. 
Through their cooperation and assistance, the research data 
collection agent can gain access to information that might 
not be available in any other way. 

Since the media research controller 300 can measure a 
panel's exposure to and interactions with the cooperative 
media handlers 1700 themselves, in addition to exposure to 
and interactions with the underlying media objects of 
interest, providers of media handlers are motivated to 
develop media handlers which cooperate with the software 
processes of the present invention, and thereby ensure that 
the media handlers provide the required functionality. In this 
manner, media handler developers can receive custom 
research reports to analyze the panel's exposure to and 
interactions with such media handlers. 

Media Terminology 

A media type is a means to represent media information, 
such as an image or a sound. For example, the PNG 
(Portable Network Graphics) file format is a media type for 
representing computer images. As used herein, a media 
object is an item or instance of a media type. Currently, there 
are hundreds of media types in use. Typically, media types 
are implemented as files, and increasingly as objects, and 
allow for some means of attaching metadata, or information 
about the data. In some cases, the metadata is implemented 
as a text field that resides in a header preceding the content 
data and can be extracted prior to decoding the content data. 
Generally, extraction of the header data is not computation- 
ally intensive, and can take place prior to or during the 
decoding and display or playback of the content. 

Every media type must have a corresponding media 
handler, located at the end-user's client side to present a 
given media object to an individual. As used herein, the term 
media handler includes persistent software components 
which extend the capabilities of a software application or an 
operating system to present media objects of a particular 
media type to an individual and autonomous software 
components, such as Java applets, which may only tempo- 
rarily extend the capabilities of the host to present media. In 
addition, the term media handler includes software applica- 
tions that generate media experiences in real-time, such as 
video games, and resident software components, such as the 
PointCast™ agent, which present media to end users. In 
addition, the term media handler includes those portions of 
an Internet browser, also called "viewers" and "plug-ins", 
that are capable and responsible for decoding specific media 
types, such as JPEG images, and using the resources of their 
host to present the media to the end user. The media handlers 
may be mobile, moving from one host computer to another, 
or stable, anchored to one host. 

Typically, an Internet browser software product has a 
collection of internal media handlers, such as JPEG and GIF 
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decoders. When a browser encounters a media object of a 
given media type, the browser transfers the media object to 
the appropriate media handler for decoding. In addition, 
most browsers incorporate "plug-in" architecture, which 
allows third parties to develop new media types and distrib- 
ute corresponding media handlers as "plug-ins." For 
example, Netscape Navigator™ currently has over two 
hundred compatible plug-ins available. 

It is noted that for continuous media, such as audio and 
video, identification tags are preferably placed at periodic 
intervals throughout the duration of the media or on an 
associated data channel. Since the identification tags might 
be utilized by hostile software to automatically remove 
advertising, the identification tags are preferably placed in 
both the advertising, as well as the associated advertising- 
supported media objects to discourage such automatic 
removal. In one preferred embodiment, discussed below in 
conjunction with FIG. 12, real identification tags are placed 
in media that is to be measured (and a fraction that is not), 
and dummy identification tags are placed in other content. 
As discussed further below, in order to permit the research 
data collection agents 1500 to be tasked by the media 
research controller 300 to report only registered media, the 
research data collection agent 1500 can preferably distin- 
guish real identification tags from dummy identification 
tags, and, if desired, return only real identification tags to the 
media research controller 300. 

Media Research Controller 

FIG. 3 is a block diagram showing the architecture of an 
illustrative media research controller 300. The media 
research controller 300 preferably includes certain standard 
hardware components, such as a central processing unit 
(CPU) 310, a random access memory (RAM) 320, a read 
only memory (ROM) 330, a clock 340, a communications 
port 350, and a data storage device 360. The CPU 310 is 
preferably linked to each of the other listed elements, either 
by means of a shared data bus, or dedicated connections, as 
shown in FIG. 3. 

The CPU 310 may be embodied as a single commercially 
available processor, such as Intel's Pentium 100 MHz P54C 
microprocessor, Motorola's 120 MHz PowerPC 604 micro- 
processor or Sun Microsystem's 166 MHz UltraSPARC-I 
microprocessor. Alternatively, the CPU 310 may be embod- 
ied as a number of such processors operating in parallel, on 
one or more distributed processing nodes. The data storage 
device 360 and/or ROM 330 are operable to store one or 
more instructions, as discussed below in conjunction with 
FIGS. 12 through 14, which the CPU 310 is operable to 
retrieve, interpret and execute. The CPU 310 preferably 
includes a control unit, an arithmetic logic unit (ALU), and 
a CPU local memory storage device, such as, for example, 
an instruction cache or a plurality of registers, in a known 
manner. The control unit is operable to retrieve instructions 
from the data storage device 360 or ROM 330. The ALU is 
operable to perform a plurality of operations needed to carry 
out instructions. The CPU local memory storage device is 
operable to provide high-speed storage used for storing 
temporary results and control information. 

As discussed further below in conjunction with FIGS. 5 
through 8, the data storage device 360 includes a central 
database 370 for storing a panel member database table 500, 
a registered media database table 600, an encryption keys 
database table 700 and a log entry database table 800. The 
panel member database table 500 preferably stores personal 
and demographic information for each member of the panel. 
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The registered media database table 600 preferably stores 
information about each media object that is registered with 
the media research controller 300, including the assigned tag 
identification number. The encryption keys database table 

5 700 preferably stores the public key/private key pairs that 
are utilized in the illustrative embodiment to implement 
secure communications. The log entry database table 800 
preferably stores information that has been extracted from or 
obtained about media objects presented to panel members 

10 and provided to the media research controller 300 by the 
remote media research agents 1500. 

In addition, as discussed further below in conjunction 
with FIGS. 12 through 14, the data storage device 360 
preferably includes a registration and tag encoding process 

15 1200, a data importing process 1300 and a reporting process 
1400. Generally, the registration and tag encoding process 
1200 registers a particular media object, and then places an 
assigned tag identification number in the registered media 
object, or otherwise associates the tag identification number 

20 with the media object. The data importing process 1300 
receives log dispatches from the remote media research 
agents 1500, verifies the authenticity and integrity of the 
received messages and places confirmed entries in the log 
entry table 800. The reporting process 1400 preferably 

25 generates reports in real-time or historically, to suit the needs 
of a particular research customer 150. 

The communications port 350 connects the media 
research controller 300 to the external networks 130, thereby 
linking the media research controller to each remote media 

30 • 

research agent, as shown in FIGS. 1 and 2. The communi- 
cations port 350 preferably includes multiple communica- 
tion channels for simultaneously connecting the media 
research controller 300 to multiple research data collection 
agents. 

35 B 

Panel Member- Computing Device 

FIG. 4 is a block diagram showing the architecture of an 
illustrative panel member-computing device 400. The panel 

40 member-computing device 400 may be embodied as any 
device which presents media to individuals, including, for 
example, an Internet-enabled device, such as a network 
computer, a set-top box, a television, a telephone, pager, or 
personal digital assistant. The panel member-computing 

45 device 400 typically includes certain standard hardware 
components, such as a central processing unit (CPU) 410, a 
random access memory (RAM) 420, a read only memory 
(ROM) 430, a clock 440, a communications port 450, and a 
data storage device 460. Each of these components 410, 420, 

50 430, 440, 450 and 460 may be identical to the corresponding 
components described above in conjunction with FIG. 2. In 
addition, the panel member-computing device 400 may 
include one or more output devices 470, such as a video 
display card and video monitor, a sound card and speaker, 

55 and one or more multimedia players 480, such as a 
CD-ROM or DVD device. 

As discussed further below in conjunction with FIGS. 9 
through 11, the data storage device 460 includes a local 
panel member database table 900, a local encryption keys 

60 database table 1000 and media queues 490. The local panel 
member database table 900 preferably stores an indication of 
whether each panel member associated with a given research 
data collection agent is currently within the scope of the 
agent. The local encryption keys database table 1000 pref- 

65 erably stores each of the public key values which are 
required by the research data collection agent 1500 to 
determine if a given extracted tag is a real tag or a dummy 
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tag and for secure communications with the media research 
controller 300. The media queues 490 preferably store 
information that has been extracted from or obtained about 
media objects presented to panel members and provided to 
the research data collection agent by the media handlers. As 
discussed further below in conjunction with FIGS. 15a 
through 15/, the media queues 490 preferably consist of an 
unfiltered media queue 1150, a filtered media queue 1170, 
each containing log entry objects 1100, and a dispatch queue 
1190, containing dispatch objects 1130. 

In addition, as discussed further below in conjunction 
with FIGS. 15 through 17, the data storage device 460 
preferably includes a research data collection (RDC) agent 
1500, a RDC/cooperative media handler host 1600 and one 
or more cooperative media handlers 1700. The research data 
collection (RDC) agent 1500 preferably includes (i) a log- 
ging process 1510 to create log entry objects from trans- 
missions received from the cooperative media handlers and 
places the log entry objects into an unfiltered media queue, 
(ii) a filtering process 1530 to confirm the integrity of the 
messages and filter out unnecessary log entry objects from 
the unfiltered media queue, using a decoding subroutine 
1550 to create a filtered media queue, (iii) a create dispatch 
process 1580 to create dispatch objects using objects from 
the filtered media queue and that places created dispatch 
objects into a dispatch queue, and (iv) a dispatch process 
1595 to transmit dispatch objects from the dispatch queue to 
the media research controller, when resources are available. 
The RDC/cooperative media handler host 1600 preferably 
provides resources and services 1675 to hosted processes 
and executes a tracking process 1605 to notify the research 
data collection agents 1500 when a panel member enters or 
exits the agent's scope. The cooperative media handlers 
1700 preferably receive and decode media objects and 
extract information from, or otherwise obtain information 
about, presented media objects, including identification tags, 
if present, for collection by research data collection agents 
1500. 

It is noted that the research data collection agent process 
1500 and related database tables 900, 1000, 1100 have been 
shown as part of the panel member-computing device 400 
for illustrative purposes only, and could be resident on a 
device physically remote from the panel member 205 in 
alternate embodiments, as previously indicated, such as part 
of the panel member's net-centric environment which is 
activated as a side effect of the person obtaining access to 
network resources, or resident or hosted within a wristwatch 
that the panel member wears. 

The communications port 450 connects the panel 
member-computing device 400 to the external networks 
130, thereby linking the computing device 400 to the media 
research controller 300 and content providers 110, 120, as 
shown in FIGS. 1 and 2. The communications port 450 
preferably includes multiple communication channels for 
simultaneous connections. 

Database Tables 

FIG. 5 illustrates an exemplary panel member database 
table 500 that preferably stores personal and demographic 
information for each member of the panel. The panel mem- 
ber database table 500 maintains a plurality of records, such 
as records 505—520, each associated with a different panel 
member. For each panel member identified by a panel 
member identifier in field 540, the panel member database 
table 500 includes the panel member's name, sex, age, city 
and state in fields 545 through 565, respectively. In addition, 
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the panel member database table 500 includes an indication 
of the member's education level and income in fields 570 
and 575, the associated research data collection agent in field 
580, and the member's email address in field 585. The panel 

5 member identifier stored in field 540 may be utilized, for 
example, to index the log entry table 800, discussed below 
in conjunction with FIG. 8. 

FIG. 6 illustrates an exemplary registered media database 
table 600 which preferably stores information about each 

10 media object which is registered with the media research 
controller 300, including the assigned tag identification 
number. The registered media database table 600 maintains 
a plurality of records, such as records 605—620, each asso- 
ciated with a different registered media object. For each 

!5 registered media object identified by a registered media 
identification number (M-J in field 640, the registered media 
database table 600 includes an indication of the entity which 
registered the object, the associated agency and the media 
type in fields 645 through 655, respectively. In addition, an 

20 encrypted and digitally signed version of registered media 
identification number preferably serves as the identification 
tag, C 2 , and is recorded in field 660. Finally, the anticipated 
starting and ending dates for which the media object will be 
distributed are recorded in fields 665 and 670. 

25 FIG. 7 illustrates an exemplary encryption keys database 
table 700 that preferably stores the public key/private key 
pairs which are utilized by the media research controller 300 
in the illustrative embodiment to implement encrypted com- 
munications with the various entities and other security 

30 features. In a preferred embodiment, the media research 
controller 300 generates public key/private key pairs and 
securely distributes the various public keys to the research 
data collection agents of the panel members. In some 
embodiments, the agents may be provided with initial public 

35 keys prior to distributing the agent. Thus, the encryption 
keys database table 700 maintains a plurality of records, 
such as records 705—720, each associated with a different 
public key/private key pair. For each pair, identified by a key 
pair identifier in field 740, the encryption keys database table 

40 700 includes an indication of the key pair owner in field 745, 
namely, the entity which holds the private key, such as the 
research data collection agent (RDC A) 1500 or the media 
research controller (MRC) 300. In addition, the encryption 
keys database table 700 includes the corresponding public 

45 key and private key values in fields 750 and 755, respec- 
tively. 

FIG. 8 illustrates an exemplary log entry database table 
800 which preferably stores information which has been 
extracted from or obtained about media objects presented to 

50 panel members and provided to the media research control- 
ler 300 by the research data collection agents, in a manner 
described further below. The log entry database table 800 
maintains a plurality of records, such as records 805—820, 
each associated with a different log entry. For each log entry 

55 identified by an entry identifier in field 830, the log entry 
database table 800 includes an identifier of the research data 
collection agent 1500, cooperative media handler 1700, and 
media handler host 1600' associated with the log entry object 
in fields 835, 840 and 842, respectively. In this manner, the 

60 research media controller 300 can generate custom reports to 
analyze a panel's exposure to and interactions with the 
media handlers 1700 and media handler hosts 1600' 
themselves, in addition to the underlying media objects of 
interest. In addition, each logged entry includes an identifier 

65 of the particular media object and panel member associated 
with the entry in fields 845 and 850, as well as date and time 
stamps in fields 855 and 860. Each entry preferably also 
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includes any metadata, contextual information, presentation 
information, and user interactions that were received in the 
log entry object, in fields 865, 870, 875 and 880, respec- 
tively. 

As shown in FIG. 8, the metadata in field 865 may include 5 
program identification information and the corresponding 
media type. The contextual information in field 870 may 
include the URL and other information indicating the source 
of the corresponding media object, or the context in which 
it was presented to the panel member. The presentation 10 
information in field 875 may include the language and 
format in which the media object was presented to the panel 
member, or other information indicating how the objected 
was presented to the panel member, when alternative pre- 
sentations are possible. Finally, the user interactions in field 15 
880 may specify how the panel member interacted with the 
object, including whether the panel member zoomed in on 
portions of the media object, or rotated the object, as well as 
the size of the media object and any user inputs. 

FIG. 9 illustrates an exemplary local panel member data- 20 
base table 900 which preferably stores a semaphore indi- 
cating whether each panel member associated with a given 
research data collection agent is currently within the scope 
of the agent. The local panel member database table 900 
maintains a plurality of records, such as records 905—915, 25 
each associated with a different panel member. For each 
panel member identified by a panel member identifier in 
field 940, the local panel member database table 900 con- 
tains a semaphore in field 945 indicating whether or not the 
panel member is in scope. 30 

FIG. 10 illustrates an exemplary local encryption keys 
database table 1000 which preferably stores each of the 
encryption key values which are required by the research 
data collection agent 1500 to determine if a given extracted 35 
tag is a real tag or a dummy tag and for secure communi- 
cations with the media research controller 300. The local 
encryption keys database table 1000 maintains a plurality of 
records, such as records 1005—1020, each associated with a 
different encryption key. For each public key identified by a 4Q 
local key identifier in field 1040, the local encryption keys 
database table 1000 includes a key pair identifier in field 
1045 and the key value in field 1050. 

FIG. 11 illustrates an exemplary log entry object 1100 
from the media queues 490, which preferably stores infor- 45 
mation which has been extracted from or obtained about a 
given media object presented to one or more panel members 
and provided to the research data collection agent 1500 by 
the cooperative media handlers 1700. The log entry object 
1100 consists of a plurality of elements, including a date/ 50 
time stamp 1102, panel member interactions 1104, media 
handler identifier 1106, presentation information 1108, iden- 
tification tag 1110, panel member identifier 1112, contextual 
information 1114, metadata 1116 and the media handler host 
identifier 1118. Each of these information types has been 55 
described above in conjunction with FIG. 8. In addition, the 
log entry object 1100 can include a copy of the media object 
itself, if desired. 

Processes 

60 

As discussed above, the media research controller 300 
preferably executes a tag registration and encoding process 
1200, shown in FIG. 12a, to register a particular media 
object, and to place an assigned tag identification number in 
the registered media object, or on a simultaneous channel. 65 
As illustrated in FIG. 12a, the media research controller 300 
begins the processes embodying the principles of the present 
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invention during step 1210 upon receipt of a request to 
register a particular media object. 

Thereafter, the media research controller 300 assigns a 
media identification key, M 1 , during step 1215 and creates a 
record of the media object in the registered media database 
table 600. In one embodiment, the identification tags are 
based on an extended version of the ISCI standard. In a 
preferred embodiment, the media research controller 300 
utilizes a doubly encrypted identification tag to protect the 
security of the media identification key, which is preferably 
never made available outside the media research controller 
300. Thus, the assigned media identification key, M 1? is 
preferably strongly encrypted with a private key, K 1? during 
step 1220 to produce a payload, C^. Thereafter, the payload, 
C 1? is digitally signed with a private key, K 2 , to create a 
digital signature, DS 1? during step 1225 and then the digital 
signature, DS 2 , is prepended to the payload, C 17 during step 
1230 to produce a new message, M 2 , shown in FIG. 126. It 
is noted that the new message, M 2 , may optionally include 
bit padding to increase C 1 to a predefined length. Finally, the 
new message, M 2 , is encrypted with a private key, K 3 , 
during step 1235 to produce a real tag, C 2 . For a more 
detailed discussion of suitable encryption and security 
techniques, see B. Schneier, Applied Cryptography (2d ed. 
1997), incorporated by reference herein. 

Thereafter, the real tag, C 2 , is placed in the media object 
during step 1240, or on a simultaneous channel, and also 
placed in field 660 of the registered media database 600. The 
identification tag can be bound to the content in a variety of 
ways. Preferably, the advertisement or other media is rep- 
resented as an object, and has been designed to implement 
the cooperative approach associated with the present inven- 
tion by reserving a field or sub-object for storing the 
identification tag. It is important that the identification tag 
does not interfere in any way with the normal use of the 
media by any media handler or media handler host that has 
not implemented the cooperative API described herein. 
Binding can be generally achieved since the most prevalent 
media file formats and datatypes support extension through 
user-defined chunks or objects. As a last resort, the identi- 
fication tag might be stored within an embedded comment 
field, into its URL, or even through steganography (hidden 
codes). 

Finally, the media object is released for distribution 
during step 1245, before program control ends during step 
1250. 

As discussed above, dummy identification tags may be 
utilized in some content to prevent hostile software from 
automatically removing advertising media objects. To pro- 
mote the use of dummy identification tags, they are prefer- 
ably constructed simply as a random sequence of n bits, as 
shown in FIG. 12c. In an alternate embodiment, the func- 
tionality for generating both real and dummy identification 
tags and encoding the identification tags into the media 
objects can be performed by third parties, such as advertis- 
ing agencies or commercial producers, including edit houses 
or production facilities. 

As discussed above, the media research controller 300 
preferably executes a data importing process 1300, shown in 
FIG. 13, to receive log dispatches from the remote media 
research agents 1500, verify the authenticity and integrity of 
the received messages and place confirmed entries in the log 
entry table 800. As illustrated in FIG. 13, the media research 
controller 300 executes the data importing process upon 
receipt of a log dispatch from a research data collection 
agent during step 1310. 
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Thereafter, the data importing process verifies the authen- 
ticity and integrity of the dispatch during step 1320 and then 
decrypts the dispatch during step 1330, Finally, the data 
importing process places all confirmed entries from the 
dispatch in the log entry database table 800 during step 1340 5 
before program control terminates during step 1350. 

As previously indicated, the media research controller 
300 preferably executes a real-time reporting process 1400, 
or a non-real-time reporting process 1400', to generate 
reports suited to the needs of a particular research customer 10 
150. As shown in FIG. 14, the data importing process 1300, 
discussed above, will create records of data received from 
the research data collection agents 1500 in a central database 
370, from which the reports will be generated. The reports 
will be formatted to present available data, in a conventional 15 
manner, according to the needs one or more research cus- 
tomers 150. The customers 150 can access the reports over 
the external networks 130, or the reports can be printed 
off-line and provided to the customer 150, as would be 
apparent to a person of ordinary skill. 20 

Research Data Collection Agent 

As shown in FIG. 15a, the research data collection agent 
1500 preferably includes a logging process 1510, a filter 25 
process 1530, a create-dispatch object process 1580 and a 
dispatch process 1595, discussed further below in conjunc- 
tion with FIGS. 15b, 15c, 15c and 15/, respectively. The 
logging process 1510 is executed by the research data 
collection agent 1500 to receive messages from cooperative 3Q 
media handlers 1700 and create entry objects in an unfiltered 
media queue 1150. The filter process 1530 is executed to 
filter out dummy tags and other unnecessary information 
from the unfiltered media queue 1150 to create a filtered 
media queue 1170. Finally, the research data collection agent 35 
1500 executes the create-dispatch object process 1580 to 
place the entries from the filtered media queue 1170 into a 
dispatch queue 1190 for transmission to the media research 
controller 300, by the dispatch process 1195 when resources 
are available. It is noted that the research data collection 4Q 
agent 1500 may also receive information regarding specific 
transactions made by an associated panel member, from a 
cooperative financial or end-user transaction process, as 
would be apparent to a person of ordinary skill, based on the 
disclosure herein. 45 

As previously indicated, the research data collection agent 
1500 executes a logging process 1510, shown in FIG. 156, 
to receive messages from the cooperative media handler 
1700 and to create entries in the unfiltered media queue 
1150. Thus, the logging process 1510 is entered during step 50 
1515 upon receipt by the research data collection agent 1500 
of a message from a cooperative media handler 1700 by 
means of the host 1600 of the media handler 1700, contain- 
ing an extracted identification tag, C 2 , if available, and other 
information. Thereafter, the logging process 1510 creates a 55 
log entry object 1100 with the identification tag and other 
received information in the unfiltered media queue 1150 
during step 1520, which is added to the tail of the unfiltered 
media queue 1150 during step 1525 before program control 
terminates during step 1528. 60 

As discussed above, the research data collection agent 
1500 periodically executes a filter process 1530, shown in 
FIG. 15c, to filter out dummy tags and other unnecessary 
information from the unfiltered media queue 1150 to create 
a filtered media queue 1170. As shown in FIG. 15c, the filter 65 
process 1530 performs a test during step 1532 to determine 
if the unfiltered media queue 1150 is empty. If it is deter- 



mined during step 1532 that the unfiltered media queue 1150 
is empty, then program control ends during step 1548. If, 
however, it is determined during step 1532 that the unfiltered 
media queue 1150 is not empty, then a log entry object 1100 
is retrieved from the head of the unfiltered media queue 1150 
during step 1534. 

Thereafter, a test is performed during step 1535 to deter- 
mine whether the media research controller 300 has 
instructed the research data collection agent 1500 to return 
information only about registered media. If it is determined 
during step 1535 that the media research controller 300 has 
not instructed the research data collection agent 1500 to 
return information only about registered media, then pro- 
gram control proceeds to step 1540. If, however, it is 
determined during step 1535 that the media research con- 
troller 300 has instructed the research data collection agent 
1500 to return information only about registered media, then 
a decoding subroutine 1550, discussed below in conjunction 
with FIG. 15d, is executed during step 1536 to determine if 
the received tag, C 2 ', stored in the current entry object 1100 
of the unfiltered media queue 1150, contains a real identi- 
fication tag, which is generally associated with registered 
media. 

After the subroutine 1550 executes, a test is performed 
during step 1538 to determine if the received tag, C 2 ', stored 
in the current log entry object 1100, contains a real identi- 
fication tag. If it is determined during step 1538 that the 
received tag, C 2 ', stored in the current log entry object 1100, 
does not contain a real identification tag, then program 
control returns directly to step 1532 to process additional log 
entry objects 1100, if any. If, however, it is determined 
during step 1538 that the received tag, C 2 , stored in the log 
entry object 1100, does contain a real identification tag, then 
the current log entry object 1100 is placed in the filtered 
media queue 1170 during step 1540. Thereafter, program 
control returns to step 1532 to process additional log entry 
objects 1100, if any, in the manner described above. 

In this manner, for efficiency purposes, if the research data 
collection agent 1500 is tasked by the media research 
controller to report only registered media, then the research 
data collection agent 1500 preferably only returns log entry 
objects 100 containing real identification tags to the media 
research controller 300. The research data collection agent 
1500 preferably does not know, however, whether or not the 
media object containing a real identification tag is an adver- 
tisement. As previously indicated, real identification tags are 
preferably placed in a small percentage of the advertising- 
subsidized media objects as a countermeasure against hostile 
advertising filtering software. Thus, if the research data 
collection agent's local encryption keys K 2 and K 3 are 
compromised and obtained by advertising filtering software, 
the advertising filtering software erroneously niters out 
some non-advertising media objects. It is noted that adver- 
tising filtering software is further discouraged by the pre- 
ferred selection of challenging encryption techniques, since 
the research data collection agent 1500 can evaluate the 
authenticity of a received tag hours after the media is 
presented, while the advertising filtering software typically 
would need to decrypt the identification tags in real-time. 

As previously indicated, the filter process 1530 executes 
a decoding subroutine 1550, shown in FIG. 15d, during step 
1536 to determine if the received tag, C 2 , stored in the 
current record of the unfiltered media log 1100, contains a 
real identification tag. The decoding subroutine 1550 is 
entered during step 1554, where the received tag, C 2 ', is 
decrypted to create a message, M 2 , using the value of the 
public key, K 3 , stored in the local encryption keys database 
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table 1000. The decoding subroutine 1550 then creates a 
digital signature, DS 1 ', from the first m bits of the message, 
M 2 f , and creates from the remainder during step 1558. 

Thereafter, a test is performed during step 1562 to deter- 
mine if the digital signature, DS/, is a valid digital signature 
of C/. If it is determined during step 1562 that the digital 
signature, DS/, is a valid digital signature of C 1 ' then the 
decoding subroutine returns an indication during step 1564 
to the filter process 1530 that the received tag is a real 
identification tag. If, however, it is determined during step 
1562 that the digital signature, DS/, is not a valid digital 
signature of then the decoding subroutine returns an 
indication during step 1568 to the filter process 1530 that the 
received tag is an invalid or dummy identification tag. In 
order to implement the security algorithms discussed in FIG. 
15d, the research data collection agent 1500 preferably has 
access to the necessary cryptographic services through its 
host, and has received the required public keys, K 2 and K 3 , 
by means of a secure distribution method from the media 
research controller 300. 

As discussed above, the research data collection agent 
1500 executes a ere ate -dispatch object process 1580, shown 
in FIG. 15e, to place entries from the filtered media queue 
1170 into a dispatch queue 1190 for transmission by the 
dispatch process 1190, shown in FIG. 15/, to the media 
research controller 300, when resources are available. 
Initially, the ere ate -dispatch object process 1580 performs a 
test during step 1581 to determine if the filtered media queue 
1170 is empty. If it is determined during step 1581 that the 
filtered media queue 1170 is empty, then program control 
ends during step 1582. 

If, however, it is determined during step 1581 that the 
filtered media queue 1170 is not empty, then a further test is 
performed during step 1583 to determine if a dispatch object 
1130 already exists. If it is determined during step 1583 that 
a dispatch object 1130 already exists, then program control 
proceeds directly to step 1585. If, however, it is determined 
during step 1583 that a dispatch object 1130 does not already 
exist, then a new dispatch object 1130 is created during step 
1584. 

Thereafter, a log entry object 1100 is retrieved from the 
head of the filtered media queue 1150 during step 1585, and 
placed in the dispatch object 1130. Thereafter, a test is 
performed during step 1587 to determine if the filtered 
media queue 1170 is empty or if the dispatch object 1130 is 
full. If it is determined during step 1585 that the filtered 
media queue 1170 is not empty and that the dispatch object 
1130 is not full, then program control returns to step 1581 to 
continue processing additional log entry objects 1100 from 
the filtered media queue 1170, if any. 

If, however, it is determined during step 1585 that the 
filtered media queue 1170 is empty or that the dispatch 
object 1130 is full, then the dispatch object 1130 will be 
compressed and digitally signed during step 1588. 
Thereafter, the compressed dispatch object 1130 will pref- 
erably be encrypted during step 1589 using the public key, 
K 4 , of the media research controller 300. Finally, the com- 
pressed and encrypted dispatch object 1130 will be added to 
the tail of the dispatch queue 1190 during step 1590 and 
program control returns to step 1581 and continues in the 
manner discussed above. 

As previously indicated, a dispatch process 1595, shown 
in FIG. 15/, transmits dispatch objects 1130 from the dis- 
patch queue 1190 to the media research controller 300, when 
resources are available. Thus, a test is initially performed 
during step 1596 to determine if the dispatch queue 1190 is 
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empty. If it is determined during step 1596 that the dispatch 
queue 1190 is empty, then program control terminates during 
step 1597. If, however, it is determined during step 1596 that 
the dispatch queue 1190 is not empty, then a dispatch object 
5 1130 is removed from the head of the dispatch queue 1190 
during step 1598 and sent to the media research controller 
300 during step 1599. Thereafter, program control returns to 
step 1596 to process additional dispatch objects 1130, if any, 
in the manner described above. 

Host Process(es) 

As previously indicated, the RDC/cooperative media han- 
dler host 1600 preferably executes a tracking process 1605, 
shown in FIG. 16, to notify the hosted research data collec- 

15 tion agents 1500 when a panel member enters or exits the 
agent's scope. In addition, as discussed above, the research 
data collection agents 1500 and the cooperative media 
handlers 1700 preferably rely on services and resources 
provided by the host processes for processing, security, 

20 storage and communication. In the illustrative embodiment 
discussed herein, an Internet browser software product, such 
as Netscape Navigator™ or Microsoft Internet Explorer™, 
resident on the panel member- computing device 400, serves 
as the host for both the research data collection agent 1500 

25 and the cooperative media handler 1700 and provides them 
with computational resources. 

Thus, as shown in FIG. 16, an illustrative tracking process 
1605 continuously reports when a panel member enters or 
exits its scope during step 1610. Once the tracking process 

30 1605 determines that a panel member has entered the scope 
of a research data collection agent, a message is sent to the 
hosted research data collection agent 1500 during step 1620 
monitoring the panel member indicating that a panel mem- 
ber has entered the agent's scope. 

35 Thereafter, the tracking process 1605 continuously moni- 
tors the panel member during step 1630 until the panel 
member leaves the scope of the hosted research data col- 
lection agent 1500. If it is determined during step 1630 that 
the panelist has left the scope of the hosted research data 

40 collection agent 1500, then a message is sent to the hosted 
research data collection agent 1500 during step 1640 indi- 
cating that a panel member has left the agent's scope. A test 
is then performed during step 1645 to determine if tracking 
should be suspended. If it is determined during step 1645 

45 that tracking should not be suspended, then program control 
returns to step 1610 to continue tracking, in the manner 
described above. If, however, it is determined during step 
1645 that tracking should be suspended, then program 
control terminates during step 1650. 

50 

Cooperative Media Handlers 

As discussed above, the cooperative media handler pro- 
cess 1700, shown in FIG. 17, preferably presents media 
objects and extracts information from, or otherwise obtains 

55 information about, presented media objects, including iden- 
tification tags, if present, for collection by research data 
collection agents 1500, whether or not a research data 
collection agent 1500 is actually present. In an alternate 
implementation, the cooperative media handler 1700 can 

60 transmit all information obtained about a media object 
directly to the media research controller 300 and perform all 
other tasks associated with the research data collection 
agents 1500. In other words, the cooperative media handler 
1700 can directly serve as the software agent of the media 

65 research controller 300, without the need of an intermediary 
research data collection agent 1500, as would be apparent to 
a person of ordinary skill. 
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In one embodiment, the media handler 1700 is provided 
with one or more remotely configurable settings which may 
be dynamically specified by the research data collection 
agent 1500 or the media research controller 300 to help filter 
out information which is not of interest to the research data 5 
collection agent 1500. Alternatively, the media handler 1700 
can query its host to identify the information of interest to 
the research data collection agent 1500. If, however, the host 
does not want to inform the media handler 1700 that no 
research data collection agent 1500 is present, the host might 10 
have the media handler 1700 pass everything. Thus, the 
media handler 1700 preferably reports information accord- 
ing to instructions received from the research data collection 
agent 1500 via its host. 

As shown in FIG. 17, a cooperative media handler 1700 1 5 
is initiated by its host 1600', such as the illustrative Internet 
browser, upon receipt of a media object having a media type 
that is compatible with the media handler. Thereafter, the 
media handler process 1700 decodes and parses the media 
object during step 1705, in a known manner. A test is then 2 o 
performed during step 1710 to determine if there is media 
object information associated with the media object, such as 
an identification tag, metadata or contextual information. As 
previously indicated, metadata may include program iden- 
tification information and the corresponding media type and 2 5 
contextual information may include the URL and other 
information indicating the source of the corresponding 
media object, or the context in which it was presented to the 
end user. If it is determined during step 1710 that there is 
media object information associated with the media object, 30 
then a test is performed during step 1785 to determine if a 
message has already been created for the research data 
collection agent 1500. If it is determined during step 1785 
that a message has already been created for the research data 
collection agent 1500, then program control proceeds 35 
directly to step 1795. If, however, it is determined during 
step 1785 that a message has not yet been created for the 
research data collection agent 1500, then a message is 
created during step 1790. 

Thereafter, the media object information identified during 40 
step 1710 is added to the agent message during step 1795. 
Thereafter, a further test is performed during step 1720 to 
determine if there is media to present to a user. If it is 
determined during step 1720 that there is no media to present 
to a user, then program control proceeds directly to step 45 
1740. If, however, it is determined during step 1720 that 
there is media to present to a user, then a conventional 
presentation process is performed during step 1725 to 
present the media. A test is then performed during step 1730 
to determine if there is presentation information to report to 50 
the research data collection agent 1500. As previously 
indicated, presentation information may include the lan- 
guage and format in which the media object was presented 
to the panel member, or other information indicating how the 
object was presented to the panel member, when alternative 55 
presentations are possible. If it is determined during step 
1730 that there is no presentation information to report to the 
research data collection agent 1500, then program control 
proceeds directly to step 1760. If, however, it is determined 
during step 1730 that there is presentation information to 60 
report to the research data collection agent 1500, then the 
presentation information identified during step 1730 is 
added to the message during step 1735. 

A test is performed during step 1740 to determine if user 
interactions are received during the presentation of the 65 
media object. If it is determined during step 1740 that user 
interactions are received during the presentation of the 



media object, then program control proceeds directly to step 
1760. If, however, it is determined during step 1740 that user 
interactions are received during the presentation of the 
media object, then the user interactions are received and 
processed during step 1745. A test is then performed during 
step 1750 to determine if there is user interaction informa- 
tion to report to the research data collection agent 1500. As 
previously indicated, user interaction information may 
specify how the panel member interacted with the object, 
including whether the panel member zoomed in on portions 
of the media object, or rotated the object, as well as the size 
of the media object and any user inputs. 

If it is determined during step 1750 that there is no user 
interaction information to report to the research data collec- 
tion agent 1500, then program control proceeds directly to 
step 1760. If, however, it is determined during step 1750 that 
there is user interaction information to report to the research 
data collection agent 1500, then the user interaction infor- 
mation identified during step 1750 is added to the message 
during step 1755. 

A test is performed during step 1760 to determine if the 
presentation of the media object is finished. If it is deter- 
mined during step 1760 that the presentation of the media 
object is not finished, then program control will return to 
step 1705 to continue processing in the manner described 
above. If, however, it is determined during step 1760 that the 
presentation of the media object is finished, then a test is 
performed during step 1765 to determine if there is a 
message to be sent to the research data collection agent 
1500. If it is determined during step 1765 that there is a 
message to be sent to the research data collection agent 
1500, then the message is completed during step 1770, for 
example, by adding media handler identifying information, 
and a final time and date stamp. Thereafter, the completed 
message is sent to the research data collection agent 1500. 
Program control will then terminate during step 1780. 

It is to be understood that the embodiments and variations 
shown and described herein are merely illustrative of the 
principles of this invention and that various modifications 
may be implemented by those skilled in the art without 
departing from the scope and spirit of the invention. 

I claim: 

1. A method performed by an independent research entity 
for measuring the exposure of an individual to electronic 
media, said method comprising the steps of: 

associating one or more software agents with said 
individual, said one or more software agents being 
agents of said independent research entity, said one or 
more software agents obtaining information identifying 
said electronic media from one or more cooperative 
media handlers provided by a second entity using a 
defined interface that provides interoperability between 
said one or more software agents and said one or more 
cooperative media handlers such that each of said one 
or more software agents and said one or more coop- 
erative media handlers can communicate without 
regard to an implementation of the defined interface of 
the other, said one or more cooperative media handlers 
providing said information identifying said electronic 
media to said one or more software agents; and 

obtaining a message from said one or more software 
agents containing said obtained information identifying 
said electronic media. 

2. The method according to claim 1, wherein said message 
further comprises information identifying said individual 
who was presented with said electronic media associated 
with said obtained information identifying said electronic 
media. 
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3. The method according to claim 1, wherein said mea- 
surement method is transparent to said individual and does 
not impose a substantial computational load on a computing 
device used by said individual. 

4. The method according to claim 1, further comprising 5 
the step of generating reports on said exposure. 

5. The method according to claim 1, wherein at least one 
of said cooperative media handlers further comprises the 
step of measuring the interactions of said individual with 
said electronic media. 10 

6. The method according to claim 1, wherein said indi- 
vidual is chosen for the individual's demographics and has 
agreed to participate in a research panel to have the indi- 
vidual's exposure to and interactions with said electronic 
media measured. 1 5 

7. The method according to claim 1, further comprising 
the step of providing a software agent for each computing 
device utilized by said individual. 

8. The method according to claim 1, wherein said infor- 
mation identifying said electronic media is an identification 2 o 
tag and further comprising the step of placing identification 
tags at periodic intervals throughout the duration of con- 
tinuous electronic media. 

9. The method according to claim 1, further comprising 
the step of placing real identification tags in said electronic 2 5 
media that is registered. 

10. The method according to claim 9, further comprising 
the steps of: 

placing dummy identification tags in at least a portion of 
electronic media that is not registered; and 30 

determining whether one of said identification tags is a 
real identification tag associated with said electronic 
media that is registered or a dummy identification tag. 

11. The method according to claim 1, further comprising 
the step of placing real identification tags in at least a portion 35 
of electronic media that is not registered. 

12. The method according to claim 1, further comprising 
the step of placing dummy identification tags in at least a 
portion of electronic media that is not registered. 

13. The method according to claim 1, further comprising 40 
the step of receiving information identifying said electronic 
media from at least one of said cooperative media handlers 

in order that electronic media presented to said individual 
not containing an identification tag may be measured. 

14. The method according to claim 1, wherein said one or 45 
more cooperative media handlers may be remotely config- 
ured to specify which portions of said information identi- 
fying said electronic media to obtain and provide to said 
software agent. 

15. The method according to claim 1, wherein said one or 50 
more cooperative media handlers filter said information 
identifying said electronic media, such that only a portion of 
said information identifying said electronic media is pro- 
vided to said software agent. 

16. The method according to claim 1, wherein said one or 55 
more cooperative media handlers filter said information 
identifying said electronic media, such that only a portion of 
said information identifying said electronic media is pro- 
vided to a research facility measuring the exposure of said 
individual to electronic media. 60 

17. The method according to claim 1, wherein said one or 
more cooperative media handlers further comprise the step 
of measuring the interactions of said individual with said 
electronic media. 

18. The method according to claim 1, wherein said 65 
information identifying said electronic media is an identifi- 
cation tag. 
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19. The method according to claim 1, wherein said 
information identifying said electronic media comprises 
metadata. 

20. The method according to claim 1, wherein said 
information identifying said electronic media comprises 
presentation information. 

21. The method according to claim 1, wherein said 
information identifying said electronic media comprises any 
contextual information made available to the one or more 
cooperative media handlers by its host. 

22. The method of claim 1, wherein said individual is part 
of an audience. 

23. The method of claim 1, wherein said individual is part 
of a research panel chosen as a sample to statistically 
represent a larger population. 

24. The method of claim 1, further comprising the steps 
of identifying and authenticating said individual. 

25. The method of claim 1, wherein said defined interface 
utilizes an application programming interface (API). 

26. The method of claim 1, wherein said defined interface 
utilizes an open communication protocol. 

27. The method of claim 1, wherein said electronic media 
includes an advertisement. 

28. The method of claim 1, wherein said electronic media 
is a software component. 

29. The method of claim 1, wherein at least one of said 
cooperative media handlers decodes and presents said elec- 
tronic media obtained from a local storage device. 

30. The method of claim 1, wherein at least one of said 
cooperative media handlers decodes and presents said elec- 
tronic media obtained from a wired network connection. 

31. The method of claim 1, wherein at least one of said 
cooperative media handlers decodes and presents said elec- 
tronic media obtained from a wireless network connection. 

32. The method of claim 1, wherein said electronic media 
is presented using an Internet-enabled device. 

33. The method of claim 1, wherein said at least one of 
said cooperative media handlers decodes and presents said 
electronic media generated in real-time. 

34. The method of claim 1, wherein at least one of said 
cooperative media handlers is a software component that 
temporarily extends the capabilities of its host to present 
media. 

35. The method of claim 1, wherein at least one of said 
cooperative media handlers is a persistent software compo- 
nent that extends the capabilities of a software application to 
present media objects of a particular media type to an 
individual. 

36. The method of claim 1, wherein at least one of said 
cooperative media handlers is a persistent software compo- 
nent that extends the capabilities or an operating system to 
present media objects of a particular media type to an 
individual. 

37. The method of claim 1, wherein at least one of said 
cooperative media handlers is mobile. 

38. The method of claim 1, wherein at least one of said 
cooperative media handlers is stable. 

39. The method of claim 1, wherein at least one of said 
software agents obtains said information identifying said 
electronic media by receiving a communication from said 
cooperative media handler. 

40. The method of claim 1, wherein at least one of said 
software agents obtains said information identifying said 
electronic media by retrieving said information identifying 
said electronic media made available by said cooperative 
media handler. 

41. A method performed by a cooperative media handler 
for presenting electronic media to an individual, said method 
comprising the steps of: 
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decoding said electronic media; 

obtaining information identifying said electronic media; 
presenting said electronic media to said individual; and 
providing said obtained information to a software agent 5 
using a defined interface that provides interoperability 
with said software agent, such that said software agent 
and said cooperative media handler can communicate 
without regard to an implementation of the defined 
interface of the other, said software agent being 
assigned to track said individual on behalf of an inde- 
pendent research entity. 

42. The method according to claim 41, further comprising 
the step of remotely configuring said cooperative media 
handler to specify which portions of said information iden- 15 
tifying said electronic media to obtain and provide to said 
software agent. 

43. The method according to claim 41, further comprising 
the step of filtering said information provided to said soft- 
ware agent. 2Q 

44. The method according to claim 41, wherein said 
cooperative media handler further comprises the step of 
measuring the interactions of said individual with said 
electronic media. 

45. The method according to claim 41, wherein said 25 
obtained information is an identification tag. 

46. The method according to claim 41, wherein said 
obtained information includes metadata. 

47. The method according to claim 41, wherein said 
obtained information includes contextual information. 3Q 

48. The method according to claim 41, wherein a software 
agent is preferably associated with each computing device 
utilized by a given individual. 

49. A method performed by a cooperative media handler 
for presenting electronic media to an individual, said method 35 
comprising the steps of: 

decoding said electronic media; 

obtaining information identifying said electronic media; 

presenting said electronic media to said individual; 

adhering to a defined interface that provides interoper- 40 
ability with a software agent associated with said 
individual, such that said software agent and said 
cooperative media handler can communicate without 
regard to an implementation of the defined interface of 
the other, said software agent being an agent of an 45 
independent research facility measuring the exposure 
of said individual to electronic, media; and 

providing said obtained information and information 
identifying said individual to said software agent using 5Q 
said defined interface. 

50. The method according to claim 49, wherein said 
obtained information is provided directly to said indepen- 
dent research facility. 

51. The method according to claim 49, wherein said 55 
obtained information is provided indirectly to said indepen- 
dent research facility by means of a software agent assigned 

to track said individual. 

52. The method according to claim 49, wherein said 
obtained information is an identification tag. 6Q 

53. The method according to claim 49, wherein said 
obtained information is a program descriptor. 

54. A cooperative media handler for presenting electronic 
media to a member of a research panel, comprising: 

means for decoding said electronic media; 65 
means for obtaining information identifying said elec- 
tronic media; 
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means for presenting said electronic media to said mem- 
ber; 

a defined interface that provides interoperability with a 
software agent associated with said individual, such 
that said software agent and said cooperative media 
handler can communicate without regard to an imple- 
mentation of the defined interface of the other, said 
software agent being an agent of an independent 
research facility measuring the exposure of said indi- 
vidual to electronic media; and 

means for providing said obtained information and infor- 
mation identifying said individual to said software 
agent using said defined interface. 

55. The cooperative media handler according to claim 54, 
wherein said obtained information is provided directly to 
said independent research facility. 

56. The cooperative media handler according to claim 54, 
wherein said obtained information is provided indirectly to 
said independent research facility by means of a software 
agent assigned to track said individual. 

57. The cooperative media handler according to claim 54, 
wherein said obtained information is an identification tag. 

58. The cooperative media handler according to claim 54, 
wherein said obtained information is metadata associated 
with said electronic media. 

59. A method performed by a software agent of a research 
entity measuring the exposure of an individual to electronic 
media, said method comprising the steps of: 

receiving information identifying said electronic media 
from one or more cooperative media handlers provided 
by a second entity using a defined interface that pro- 
vides interoperability with said one or more coopera- 
tive media handlers, such that said software agent and 
each of said one or more cooperative media handlers 
can utilize said defined interface to communicate with- 
out regard to an implementation of the defined interface 
of the other; and 

providing a message containing at least a portion of said 
information to said research entity measuring the expo- 
sure of said individual to electronic media. 

60. The method according to claim 59, wherein said 
measurement method is transparent to said individual and 
does not impose a substantial computational load on a 
computing device used by said individual. 

61. The method according to claim 59, wherein a software 
agent is preferably associated with each computing device 
utilized by a given individual. 

62. The method according to claim 61, wherein said 
software agent filters said messages provided to said 
research entity. 

63. A method of obtaining information identifying an 
electronic media object, said method comprising the steps 
of: 

providing a cooperative media handler to decode said 
electronic media object, said cooperative media handler 
obtaining said information from said electronic media; 

presenting said electronic media object to an individual; 
and 

providing said obtained information for collection by a 
software agent using a defined interface that provides 
interoperability between said software agent and said 
cooperative media handler, such that said software 
agent and said cooperative media handler can utilize 
said defined interface to communicate without regard to 
an implementation of the defined interface of the other, 
said software agent being assigned to track one or more 
individuals on behalf of an independent research entity. 
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64. The method according to claim 63, further comprising 
the step of generating reports on said exposure. 

65. The method according to claim 63, further comprising 
the step of measuring the interactions of said individual with 
said electronic media. 

66. The method according to claim 63, further comprising 
the step of providing a software agent for each computing 
device utilized by a given panel member. 

67. A method performed by an independent research 
entity for measuring the exposure of an individual to elec- 
tronic media, said method comprising the steps of: 

establishing an interface for communications between a 
research data collection agent and a plurality of coop- 
erative media handlers, said defined interface permit- 
ting said research data collection agent and each of said 
cooperative media handlers to communicate without 
regard to an implementation of the defined interface of 
the other, wherein said cooperative media handlers 
present media to said individual and gather presentation 
information about media presentations and wherein 
said research data collection agent collects said pre- 
sentation information from said cooperative media han- 
dlers on behalf of said independent research entity; and 

associating at least one research data collection agent with 
said individual, said research data collection agent 
adhering to said interface, said research data collection 
agent obtaining presentation information from said 
cooperative media handlers by means of said interface 
and forwarding at least a portion of said presentation 
information to said independent research entity. 

68. The method according to claim 67, wherein said 
presentation information further comprises information 
identifying said individual who was presented with said 
electronic media. 

69. The method according to claim 67, further comprising 
the step of generating reports on said exposure. 

70. The method according to claim 67, wherein at least 
one of said cooperative media handlers further comprises the 
step of measuring the interactions of said individual with 
said electronic media. 

71. The method according to claim 67, wherein said 
individual is chosen for the individuals demographics and 
has agreed to participate in a research panel to have the 
individual's exposure to and interactions with said electronic 
media measured. 

72. The method according to claim 67, further comprising 
the step of receiving information identifying said electronic 
media from at least one of said cooperative media handlers 
in order that electronic media presented to said individual 
not containing an identification tag may be measured. 

73. The method according to claim 67, wherein said one 
or more cooperative media handlers may be remotely con- 
figured to specify which portions of said presentation infor- 
mation to obtain and provide to said research data collection 
agent. 

74. The method according to claim 67, wherein said one 
or more cooperative media handler filter said presentation 
information such that only a portion of said presentation 
information is provided to said software agent. 

75. The method according to claim 67, wherein said one 
or more cooperative media handlers filter said presentation 
information such that only a portion of said presentation 
information is provided to a research facility measuring the 
exposure of said individual to electronic media. 
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76. The method according to claim 67, wherein said one 
or more cooperative media handlers further comprise the 
step of measuring the interactions of said individual with 
said electronic media. 
5 77. The method according to claim 67, wherein said 
presentation information includes an identification tag. 

78. The method according to claim 67, wherein said 
presentation information comprises metadata. 
10 79. The method according to claim 67, wherein said 
presentation information comprises any contextual informa- 
tion made available to the one or more cooperative media 
handlers by its host. 

80. The method according to claim 67, wherein said 
15 individual is part of an audience. 

81. The method according to claim 67, wherein said 
individual is part of a research panel chosen as a sample to 
statistically represent a larger population. 

20 82. The method according to claim 67, further comprising 
the steps of identifying and authenticating said individual. 

83. The method according to claim 67, wherein said 
defined interface utilizes an application programming inter- 
face (API). 

25 84. The method according to claim 67, wherein said 
denned interface utilizes an open communication protocol. 

85. The method according to claim 67, wherein said 
electronic media includes an advertisement. 

30 86. The method according to claim 67, wherein said 
electronic media is a software component. 

87. The method according to claim 67, wherein at least 
one of said cooperative media handlers decodes and presents 
said electronic media obtained from a local storage device. 

35 88. The method according to claim 67, wherein at least 
one of said cooperative media handlers decodes and presents 
said electronic media obtained from a wired network con- 
nection. 

89. The method according to claim 67, wherein at least 

40 

one of said cooperative media handlers decodes and presents 
said electronic media obtained from a wireless network 
connection. 

90. The method according to claim 67, wherein said 
45 electronic media is presented using an Internet-enabled 

device. 

91. The method according to claim 67, wherein said at 
least one of said cooperative media handlers decodes and 
presents said electronic media generated in real-time. 

92. The method according to claim 67, wherein at least 
one of said cooperative media handlers is a software com- 
ponent that temporarily extends the capabilities of its host to 
present media. 

55 93. The method according to claim 67, wherein at least 
one of said cooperative media handlers is a persistent 
software component that extends the capabilities of a soft- 
ware application to present media objects of a particular 
media type to an individual. 

60 94. The method according to claim 67, wherein at least 
one of said cooperative media handlers is a persistent 
software component that extends the capabilities of an 
operating system to present media objects of a particular 

65 media type to an individual. 

95. The method according to claim 67, wherein at least 
one of said cooperative media handlers is mobile. 
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96. The method according to claim 67, wherein at least 
one of said cooperative media handler is stable. 

97. The method according to claim 67, wherein at least 
one of said research data collection agents obtains said 
presentation information by receiving a communication 5 
from at least one of said cooperative media handlers. 

98. The method according to claim 67, wherein at least 
one of said research data collection agents obtains said 
presentation information identifying said electronic media 
by retrieving said information identifying said electronic 
media made available by at least one of said cooperative 
media handlers. 

99. A cooperative system employed by an independent 
research entity for measuring the exposure of an individual 15 
to electronic media, said cooperative system comprising: 

a memory that stores computer-readable code; 

a processor operatively coupled to said memory, said 
processor configured to execute said computer- 
readable code, said computer-readable code configured 2 o 
to associate one or more software agents with said 
individual, said one or more software agents being 
agents of said independent research entity, said one or 
more software agents obtaining information identifying 
said electronic media from one or more cooperative ^ 
media handlers provided by a second entity using a 
defined interface that provides interoperability between 
said one or more software agents and said one or more 
cooperative media handlers such that each of said one 
or more software agents and each of said one or more 
cooperative media handlers can communicate without 30 
regard to an implementation of the defined interface of 
the other, said cooperative media handler providing 
said information identifying said electronic media to 
said one or more software agents; and 

a communication port that obtains a message from said 35 
software agent containing said obtained information 
identifying said electronic media. 

100. The cooperative system according to claim 99, 
wherein said message further comprises information iden- ^ 
tifying said individual who was presented with said elec- 
tronic media associated with said obtained information 
identifying said electronic media. 

101. The cooperative system according to claim 99, 
wherein said processor is further configured to generate 45 
reports on said exposure. 

102. The cooperative system according to claim 99, 
wherein said processor is further configured to receive 
information identifying said electronic media in order that 
electronic media presented to said individual not containing 
an identification tag may be measured. 

103. The cooperative system according to claim 99, 
wherein said one or more cooperative media handlers may 

be remotely configured to specify which portions of said 55 
information identifying said electronic media to obtain and 
provide to said software agent. 

104. The cooperative system according to claim 99, 
wherein said one or more cooperative media handlers are 
configured to measure the interactions of said individual 60 
with said electronic media. 

105. The method according to claim 99, wherein said 
information includes an identification tag. 

106. The cooperative system according to claim 99, 65 
wherein said defined interface utilizes an application pro- 
gramming interface (API). 
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107. The cooperative system according to claim 99, 
wherein said defined interface utilizes an open communica- 
tion protocol. 

108. The cooperative system according to claim 99, 
wherein said electronic media includes an advertisement. 

109. The cooperative system according to claim 99, 
wherein said electronic media is a software component. 

110. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers 
decodes and presents said electronic media obtained from a 
local storage device. 

111. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers 
decodes and presents said electronic media obtained from a 
wired network connection. 

112. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers 
decodes and presents said electronic media obtained from a 
wireless network connection. 

113. The cooperative system according to claim 99, 
wherein said electronic media is presented using an Internet- 
enabled device. 

114. The cooperative system according to claim 99, 
wherein said at least one of said cooperative media handlers 
decodes and presents said electronic media generated in 
real-time. 

115. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers is a 
software component that temporarily extends the capabili- 
ties of its host to present media. 

116. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers is a 
persistent software component that extends the capabilities 
of a software application to present media objects of a 
particular media type to an individual. 

117. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers is a 
persistent software component that extends the capabilities 
of an operating system to present media objects of a par- 
ticular media type to an individual. 

118. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers is 
mobile. 

119. The cooperative system according to claim 99, 
wherein at least one of said cooperative media handlers is 
stable. 

120. A cooperative system for presenting electronic media 
to an individual, said cooperative system comprising: 

a memory that stores computer- readable code; and 
a processor operatively coupled to said memory, said 
processor configured to execute said computer- 
readable code, said computer-readable code containing: 
cooperative media handler instructions to: 
present media to said individual; and 
gather presentation information about media presen- 
tations; 

research data collection agent instructions to collect 
said presentation information on behalf of an inde- 
pendent research entity; and 

an interface for communications between a research 
data collection agent and a plurality of cooperative 
media handlers, said defined interface permitting 
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said research data collection agent and each of said 
cooperative media handlers to communicate without 
regard to an implementation of the defined interface 
of the other. 

121. The cooperative system according to claim 120, 
wherein said cooperative media handler instructions further 
include instructions to measure the interactions of said 
individual with said electronic media. 

122. The cooperative system according to claim 120, 
wherein said cooperative media handler instructions further 
include instructions to filter said presentation information 
such that only a portion of said presentation information is 
provided to said software agent. 

123. The cooperative system according to claim 120, 
wherein said cooperative media handler instructions further 
include instructions to filter said presentation information 
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such that only a portion of said presentation information is 
provided to a research facility measuring the exposure of 
said individual to electronic media. 

124. The cooperative system according to claim 120, 
wherein said cooperative media handler instructions further 
include instructions to measure the interactions of said 
individual with said electronic media. 

125. The cooperative system according to claim 120, 
wherein said defined interface utilizes an application pro- 
gramming interface (API). 

126. The cooperative system according to claim 120, 
wherein said defined interface utilizes an open communica- 
tion protocol. 
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ABSTRACT 



Packetized program information used in video processing 
and storage medium formats includes multiple text strings. 
A decoder decodes packetized program information contain- 
ing multiple text strings associated with a program. The 
decoder determines from a first indicator in the packetized 
program information a type of coding and compression 
employed in encoding a first text string. The decoder 
decodes the first text string with a decoding function 
selected in accordance with the determined type of coding 
and assembles decoded text string elements to form an 
output text string. 

20 Claims, 7 Drawing Sheets 



Bit Stream Syntax for the Service Location Descriptor 



Syntax gfa 


Format 


multiple_compressed_strings{) { 




- — number_strings 8 


uimsbf 


for (i = 0;i< number_strings;i++) { 




numberjjytes ig 


uimsbf 


^- ISO_639_language_code 8*3 


uimsbf 


^ — codingjndicator 8 


bslbf 


— compressionjype 8 


uimsbf 


f for (j =0;j<number_bytes;j++) 




compressed string bypejj] 8 

} 

} 


uimsbf 



compressionjype 


compression method 


0x00 


No compression 


0x01 


Huffman coding based an the 
default Huffman table 


0x02 


LZW 


0x03 to OxAF 


reserved 


OxBO to OxFF 


user private 



codingjndicator 


coding method 


0x00 


Unicode 


0x01 


Latin-1 


0x02 


Latin-2 


0x03 to OxAF 


reserved 


OxBO to OxFF 


user private 
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Bit Stream Syntax for the Master Guide Table 



Oyi lldX 


Bits 


Format 


master nuirip tahlp ^prtinn (\ 1 






tahlp id 


Q 
O 


uxEO 


^pption ^x/ntaY inr\\ratr\r 


1 


1 


nrk/atp inHiratnr 

IVOLCII 1 LI IV- a LL/l 


1 
1 


1 


reserved 


0 

c 


1 1 


orivate section lenoth 




UllTlSDr 


table id PYtpn^inn 


1 D 


uxuuuu 


reserved 


? 


i-i ii 
i i 


vprcinn ni imhpr 


C 

D 


uimsDT 


currpnt nPYt indirat nr 

VxCil 1 1 1- 1 ICAl n il 1 VJlL*Cl LL/l 


1 
1 


1 


^pptinn ni imhpr 

OCV. LIUI I 1 IUI 1 lUCI 


p 
0 


uxuu 


last section number 


Q 
o 


uxuu 


reserved 


Q 
0 


1 1 1 


CRT vprcinn ni imhpr 

L^l \ 1 _VCI OIL/1 1 1 ILJI 1 1 L/d 


c 


uimsur 


zero 


4 


uuuu 


ni im nn 

1 IUI 1 l_U\J 


d 


uimsDr 


for ^ i =0'i< num dom-m-I Pfifrt 1 






- " — - — annliration timp 

CJ^-rltsllLoGI L IL/I l_^LII 1 IC 




uimsDr 


duration 


Ifi 
1 O 


Ull 1 loUl 


reserved 


? 


f 1 V 


CU _flag 


1 


blsbf 


num_bytes 


21 


uimsbf 




0 


•1 1 1 1 
1 1 1 


pid pg m 

• ' ™*^_l II 1 


1 o 


Uli i loUl 


reserved 




! 1 1 V 
I 1 f 


RD ETT HI 

- * ■ • 1 III 


13 

1 sj 


i limchf 

Ull 1 loUl 


reserved 


4 


uimsbf 


PG _descriptors_length 


12 


uimsbf 


forfi = 0"i<M'i++) 

i v-/i yj — • L/ji^-s i*itj l i J 






descriptor () 

} 

reserved 


var 




4 


uimsbf 


descriptors Jength 


12 


uimsbf 


for (i =0;i<N;j++) 






descriptor () 


var 




CRC_32 

} 


32 


rpchof 



220 

215 
210 



205 



FIGURE 2 
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Bit Stream Syntax for the Channel Information Table 



Syntax 



Bits 



Format 



++ 



channel_guide_table_section () { 
tablejd 

section_syntax_indicator 
privatejndicator 
reserved 
sectionjength 
table_id_extenslon 
reserved 
version_number 
current_next_indicator 
section_number 
last_section_number 
num_channels_in_section 
for (k=0; k<num_channels_in_section;k 
short_name 
channel_visibility 
bundle_channel_number{ 
bundle_number 
■ channel_number_in_bundle 

ChanneLPTC 
channeljd 
channeljype 
reserved 
ETMJIag 

descriptors_length 

for(i=0;i<N;i++){ 
descriptors() 



CRC 32 




8 
1 
1 
2 
12 
16 
2 
5 
1 
8 
8 
8 

) cha_info(k){ 
8*6 
32 

12 
12 

8 

16 
8 
3 
1 

12 



0xE3 
T 
'1' 
'11' 

uimsbf 
uimsbf 
'11' 

uimsbf 
'1' 

uimsbf 
uimsbf 
uimsbf 

ISO-639 
bslbf 

uimsbf 
uimsbf 

uimsbf 

uimsbf 

uimsbf 

'111' 

bslbf 

uimsbf 



32 



rpchof 



FIGURE 3 
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Bit Stream Syntax for the Service Location Descriptor 



Syntax 



Bits 



Format 



serviceJocation_descriptor() { 



descriptorjag 


8 


uimsbf 


descriptorjength 


8 


uimsbf 


program_number 


16 


uimsbf 


reserved 


3 


'111* 


PCR_PID 


13 


uimsbf 


number_PIDs 


8 


uimsbf 


for(i=1;i<number_PIDs;i++){ 






stream_type 


8 


uimsbf 


reserved 


3 


bslbf 


elementary.PID 


13 


uimsbf 


ISO_639_language_code 


8*3 


uimsbf 
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Bit Stream Syntax for the 


Service 


Location 


Descriptor 


Syntax 




Bits 


Format 


e^endecLtext_tatie_3ection 


(){ 






tableud 


8 


QxE5 


sectiorusyntaxjndcator 




1 


V 


privatejndicator 




1 


T 


reserved 




2 


■IT 


pnvate_sectionJength 




12 


uimsbf 


" — ETMJd 




32 


bsbf 


— - extendecLtext_message 


0 


var 



FIGURE 5 



Bit 


1 2 


3 18 


19 32 


channe} ETVLd 


0 0 


charrieLid 


1 1 1 .1 1 


event ETMJd 


1 0 


chameUd 


evenUd 



605 

FIGURE 6 
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Bit Stream Syntax for the Service Location Descriptor 



Syntax 



Bits 



Format 




muitiple_compressed_strings () { 
— number_strings 

for (i = 0;i< number_strings;i++) { 
n umber J>ytes 
ISO_639_language_code 
codingjndicator 
compressionjype 
(j = 0;j<number_bytes;j++) 

compressed_string_bype [j] 



8 


uimsbf 


16 


uimsbf 


8*3 


uimsbf 


8 


bslbf 


8 


uimsbf 


8 


uimsbf 



FIGURE 7 



compressionjype 


compression method 


0x00 


No compression 


0x01 


Huffman coding based on the 
default Huffman table 


0x02 


LZW 


0x03 to OxAF 


reserved 


OxBO to OxFF 


user private 



FIGURE 8 



codingjndicator 


coding method 


0x00 


Unicode 


0x01 


Latin-1 


0x02 


Latin-2 


0x03 to OxAF 


reserved 


OxBO to OxFF 


user private 



FIGURE 9 
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FIGURE 10 



.START 



800 



GENERATE CHANNEL INFORMATION TABLE (CIT) 
INCORPORATING: 

1) DUAL CHANNEL IDENTIFICATION NUMBERS, & 

2) A SERVICE LOCATION DESCRIPTOR (SLD) 



I 



810 



GENERATE AN EVENT INFORMATION TABLE (EIT) 
INCORPORATING PROGRAM GUIDE INFORMATION 
DESCRIBING AVAILABLE PROGRAMS AND CHANNELS 



T 



815 



GENERATE AN EXTENDED TEXT TABLE (ETT) INCORPORATING: 

1) SEGMENTED TEXT MESSAGES, & 

2) COMPRESSION, LANGUAGE AND CODING TYPE 
INDICATORS 



I 



'820 





GENERATE MASTER GUIDE TABLE (MGT) 
INCORPORATING IDENTIFIERS FOR USE 
IN ASSEMBLING OTHER TABLES 








^"822 

r 




FORMAT PROGRAM SPECIFIC INFORMATION 
INCORPORATING MGT, CIT, EIT, ETT AND DESCRIPTORS 



I 



825 



INCORPORATE PROGRAM SPECIFIC INFORMATION 
INTO VIDEO PROGRAM DATASTREAM TO FORM 
VIDEO OUTPUT DATA 



T 



830 



PROCESS VIDEO OUTPUT DATA 
FOR TRANSMISSION 



835 




END 



840 
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SYSTEM FOR FORMING AND PROCESSING 
PROGRAM SPECIFIC INFORMATION 
CONTAINING TEXT DATA FOR 
TERRESTRIAL, CABLE OR SATELLITE 
BROADCAST 

This is a non-provisional application of provisional 
application Ser. No. 60/052,152 by E. A. Heredia et al, filed 
Jul. 10, 1997. 

FIELD OF THE INVENTION 

This invention is related to the formation of Program 
Guides, system information and program specific informa- 
tion for MPEG compatible processing. 

BACKGROUND OF THE INVENTION 

In video broadcast and processing applications, digital 
video data is typically encoded to conform to the require- 
ments of a known standard. One such widely adopted 
standard is the MPEG2 (Moving Pictures Expert Group) 
image encoding standard, hereinafter referred to as the 
"MPEG standard". The MPEG standard is comprised of a 
system encoding section (ISO/IEC 13818-1, 10th Jun. 1994) 
and a video encoding section (ISO/IEC 13818-2, 20th Jan. 
1995). Data encoded to the MPEG standard is in the form of 
a packetized datastream which typically includes the data 
content of many program channels (e.g. content correspond- 
ing to cable television channels 1-125). Further, several 
digital services and channels may occupy the frequency 
spectrum previously occupied by a single analog channel. A 
6 MHz bandwidth previously allocated to an analog NTSC 
compatible broadcast channel may now be split into a 
number of digital sub-channels offering a variety of services. 
For example, the broadcast spectrum for RF channel 13 may 
be allocated to sub-channels including a main program 
channel, a financial service channel offering stock quotes, a 
sports news service channel and a shopping and interactive 
channel. In addition, both the quantity of sub-channels 
transmitted and the individual sub-channel bandwidth may 
be changed dynamically to accommodate changing broad- 
cast programming requirements. 

In such a digital video system the proliferation in the 
quantity of services being broadcast and the increased 
variety of their content, as well as the ability of a broadcaster 
to dynamically vary the number and allocated bandwidth of 
these channels poses a number of problems. Specifically, the 
increase in the quantity of broadcast channels may increase 
the difficulty of tuning and lengthen the time required to 
acquire a selected program channel. Further, as the quantity 
of channels increases so does the quantity of ancillary 
program specific information required in decoding the trans- 
mitted program data. The ancillary program specific infor- 
mation includes data used in identifying and assembling 
packets comprising selected programs and also includes 
program guide and text information associated with the 
transmitted program data. The increased quantity and vari- 
ety of ancillary information transmitted places an additional 
burden on available transmission bandwidth and receiver 
decoding and storage resources. 

In addition, channel numbering in such a digital video 
system may present a problem. This is because a broadcaster 
may not want to lose an original analog NTSC broadcast 
channel number even though the broadcaster is transmitting 
several program channels in the frequency spectrum previ- 
ously occupied by the single analog program channel. The 
broadcaster may have a significant investment in the channel 



number as a brand identity e.g. Fox 5™, Channel 13™. 
These problems and derivative problems are addressed by a 
system according to the present invention. 

5 SUMMARY OF THE INVENTION 

A decoder decodes packetized program information con- 
taining multiple text strings associated with a program. The 
decoder determines from a first indicator in the packetized 
program information a type of coding and compression 
employed in encoding a first text string. The decoder 
decodes the first text string with a decoding function 
selected in accordance with the determined type of coding 
and assembles decoded text string elements to form an 
^ output text string. 

BRIEF DESCRIPTION OF THE DRAWINGS 
In the drawing: 

FIG. 1 is a block diagram of digital video receiving 
20 apparatus for demodulating and decoding broadcast signals, 
according to the principles of the invention. 

FIG. 2 shows a Master Guide Table (MGT) format for use 
in conveying program specific information, according to the 
invention. 

25 

FIG. 3 shows a Channel Information Table (CIT) format 
for use in conveying program specific information incorpo- 
rating dual program channel identification numbers, accord- 
ing to the invention. 
30 FIG. 4 shows a Service Location Descriptor (SLD) format 
for use in conveying program specific information incorpo- 
rating program map information, according to the invention. 

FIG. 5 shows a program specific information text format 
for use in conveying program related text information, 
35 according to the invention. 

FIG. 6 shows a scheme for assigning a text message 
identifier as used in the text format of FIG. 5. 

FIG. 7 shows a multiple compressed text string format for 
use in conveying program related text information, accord- 
40 ing to the invention. 

FIGS. 8 and 9 show exemplary indicator definitions for 
compression and coding indicators within the multiple com- 
pressed text string format of FIG. 7. 
45 FIG. 10 shows a method for generating program specific 
information according to the invention. 

DETAILED DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a digital video receiving 

50 system for demodulating and decoding broadcast signals, 
according to the principles of the invention. Although the 
disclosed system is described in the context of a system for 
receiving video signals incorporating program specific infor- 
mation including program guide data in MPEG compatible 

55 format, it is exemplary only. The program specific informa- 
tion may be of a variety of types. For example, it may 
comply with Program Specific Information (PSI) require- 
ments specified in section 2.4.4 of the MPEG systems 
standard or it may comply with the high definition television 

60 (HDTV) signal standard Digital Television Standard for 
HDTV Transmission of Apr. 12 1995, prepared by the United 
States Advanced Television Systems Committee (ATSC) or 
other ATSC standards. Alternatively, it may be formed in 
accordance with proprietary or custom requirements of a 

65 particular system. 

The principles of the invention may be applied to 
terrestrial, cable, satellite, Internet or computer network 
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broadcast systems in which the coding type or modulation 
format may be varied. Such systems may include, for 
example, non-MPEG compatible systems, involving other 
types of encoded datastreams and other methods of convey- 
ing program specific information. Further, although the 5 
disclosed system is described as processing broadcast 
programs, this is exemplary only. The term 'program' is used 
to represent any form of packetized data such as audio data, 
telephone messages, computer programs, Internet data or 
other communications, for example. 10 

In overview, in the video receiver system of FIG. 1, a 
broadcast carrier modulated with signals carrying audio, 
video and associated data representing broadcast program 
content is received by antenna 10 and processed by unit 13. 
The resultant digital output signal is demodulated by ^ 
demodulator 15. The demodulated output from unit 15 is 
trellis decoded, mapped into byte length data segments, 
deinterleaved and Reed-Solomon error corrected by decoder 
17. The corrected output data from unit 17 is in the form of 
an MPEG compatible transport datastream containing pro- 2 o 
gram representative multiplexed audio, video and data com- 
ponents. The transport stream from unit 17 is demultiplexed 
into audio, video and data components by unit 22 which are 
further processed by the other elements of decoder system 
100. In one mode, decoder 100 provides MPEG decoded 2 5 
data for display and audio reproduction on units 50 and 55 
respectively. In another mode, the transport stream from unit 
17 is processed by decoder 100 to provide an MPEG 
compatible datastream for storage on storage medium 105 
via storage device 90. 30 

A user selects for viewing either a TV channel or an 
on-screen menu, such as a program guide, by using a remote 
control unit 70. Processor 60 uses the selection information 
provided from remote control unit 70 via interface 65 to 
appropriately configure the elements of FIG. 1 to receive a 35 
desired program channel for viewing. Processor 60 com- 
prises processor 62 and controller 64. Unit 62 processes (i.e. 
parses, collates and assembles) program specific information 
including program guide and system information and con- 
troller 64 performs the remaining control functions required 40 
in operating decoder 100. Although the functions of unit 60 
may be implemented as separate elements 62 and 64 as 
depicted in FIG. 1, they may alternatively be implemented 
within a single processor. For example, the functions of units 
62 and 64 may b e incorporated within the programmed 45 
instructions of a microprocessor. Processor 60 configures 
processor 13, demodulator 15, decoder 17 and decoder 
system 100 to demodulate and decode the input signal 
format and coding type. Units 13, 15, 17 and sub-units 
within decoder 100 are individually configured for the input 50 
signal type by processor 60 setting control register values 
within these elements using a bi-directional data and control 
signal bus C. 

The transport stream provided to decoder 100 comprises 
data packets containing program channel data and program 55 
specific information. Unit 22 directs the program specific 
information packets to processor 60 which parses, collates 
and assembles this information into hierarchically arranged 
tables. Individual data packets comprising the User selected 
program channel are identified and assembled using the 60 
assembled program specific information. The program spe- 
cific information contains conditional access, network infor- 
mation and identification and linking data enabling the 
system of FIG. 1 to tune to a desired channel and assemble 
data packets to form complete programs. The program 65 
specific information also contains ancillary program guide 
information (e.g. an Electronic Program Guide — EPG) and 
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descriptive text related to the broadcast programs as well as 
data supporting the identification and assembly of this 
ancillary information. 

The program specific information is assembled by pro- 
cessor 60 into multiple hierarchically arranged and inter- 
linked tables. An exemplary hierarchical table arrangement 
includes a Master Guide Table (MGT), a Channel Informa- 
tion Table (CIT), Event Information Tables (EITs) and 
optional tables such as Extended Text Tables (ETTs). The 
MGT contains information for acquiring program specific 
information conveyed in other tables such as identifiers for 
identifying data packets associated with the other tables. The 
CIT contains information for tuning and navigation to 
receive a User selected program channel. The EIT contains 
descriptive lists of programs (events) receivable on the 
channels listed in the CIT. The ETT contains text messages 
describing programs and program channels. Additional pro- 
gram specific information describing and supplementing 
items within the hierarchical tables is conveyed within 
descriptor information elements. The program specific infor- 
mation acquired by processor 60 via unit 22 is stored within 
internal memory of unit 60. 

Considering FIG. 1 in detail, a carrier modulated with 
signals carrying program representative audio, video and 
associated data received by antenna 10, is converted to 
digital form and processed by input processor 13. Processor 
13 includes radio frequency (RF) tuner and intermediate 
frequency (IF) mixer and amplification stages for down- 
converting the input signal to a lower frequency band 
suitable for further processing. In this exemplary system, the 
input signal received by antenna 10 contains 33 Physical 
Transmission Channels (PTCs 0-32). Each Physical Trans- 
mission Channel (PTC) is allocated a 6 MHz bandwidth and 
contains, for example, up to 6 sub-channels. 

It is assumed for exemplary purposes that a video receiver 
user selects a sub-channel (SC) for viewing using remote 
control unit 70. Processor 60 uses the selection information 
provided from remote control unit 70 via interface 65 to 
appropriately configure the elements of decoder 100 to 
receive the PTC corresponding to the selected sub-channel 
SC. Following down conversion, the output signal from unit 
13 for the selected PTC has a bandwidth of 6 MHz and a 
center frequency in the range of 119^-05 MHz. In the 
following discussion, an RF channel or Physical Transmis- 
sion Channel (PTC) refers to an allocated broadcaster trans- 
mission channel band which encompasses one or more 
sub-channels (also termed virtual or logical channels). 

Processor 60 configures the radio frequency (RF) tuner 
and intermediate frequency (IF) mixer and amplification 
stages of unit 13 to receive the selected PTC. The down- 
converted frequency output for the selected PTC is demodu- 
lated by unit 15. The primary functions of demodulator 15 
are recovery and tracking of the carrier frequency, recovery 
of the transmitted data clock frequency, and recovery of the 
video data itself. Unit 15 also recovers sampling and syn- 
chronization clocks that correspond to transmitter clocks and 
are used for timing the operation of processor 13, demodu- 
lator 15 and decoder 17. The recovered output from unit 15 
is provided to decoder 17. 

The output from demodulator 15 is mapped into byte 
length data segments, deinterleaved and Reed-Solomon 
error corrected according to known principles by unit 17. In 
addition, unit 17 provides a Forward Error Correction (FEC) 
validity or lock indication to processor 60. Reed-Solomon 
error correction is a known type of Forward Error Correc- 
tion. The FEC lock indication signals that the Reed-Solomon 
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error correction is synchronized to the data being corrected 
and is providing a valid output. It is to be noted that the 
demodulator and decoder functions implemented by units 
13, 15 and 17 are individually known and generally 
described, for example, in the reference text Digital 5 
Communication, Lee and Messerschmidt (Kluwer Academic 
Press, Boston, Mass., USA, 1988). 

The corrected output data from unit 17 is processed by 
MPEG compatible transport processor and demultiplexer 
22. The individual packets that comprise either particular 10 
program channel content, or program specific information, 
are identified by their Packet Identifiers (PIDs). Processor 22 
separates data according to type based on an analysis of 
Packet Identifiers (PIDs) contained within packet header 
information and provides synchronization and error indica- 15 
tion information used in subsequent video, audio and data 
decompression. 

The corrected output data provided to processor 22 is in 
the form of a transport datastream containing program 
channel content and program specific information for many 2 o 
programs distributed through several sub-channels. The pro- 
gram specific information in this exemplary description 
describes sub-channels present in a transport stream of a 
particular PTC. However, in another embodiment the pro- 
gram specific information may also describe sub-channels 2 5 
located in other PTCs and conveyed in different transport 
streams. Groups of these sub-channels may be associated in 
that their source is a particular broadcaster or they occupy 
the transmission bandwidth previously allocated to an ana- 
log NTSC compatible broadcast channel. Further, individual 30 
packets that comprise a selected program channel in the 
transport stream are identified and assembled by processor 
60 operating in conjunction with processor 22 using PIDs 
contained in the program specific information. 

The program specific information is in the form of hier- 35 
archically arranged tables including an MGT, CIT, EIT, and 
ETT together with supplementary descriptor information. 
The PID that identifies packets comprising the MGT data is 
predetermined and stored within processor 60 internal 
memory. Further, the MGT conveys the PIDs that identify 40 
the CIT, EIT, and ETT data and conveys other information 
indicating the size of these tables. Processor 60 monitors the 
MGT for updates to identify any changes in PIDs or table 
sizes. Therefore, after processor 60 determines from the 
FEC lock indication provided by unit 17 that valid data is 45 
being provided to transport processor 22, the MGT may be 
acquired without additional PID information. Using Control 
signal C, processor 60 configures transport processor 22 to 
select the data packets comprising the remaining program 
specific information including the CIT, EIT and ETT data. 50 
Processor 22 matches the PIDs of incoming packets pro- 
vided by unit 17 with PID values pre-loaded in control 
registers within unit 22 by processor 60. Further, processor 
60 accesses, parses and assembles the program specific 
information packets captured by processor 22 and stores the 55 
program specific information within its internal memory. 
Processor 60 derives tuning parameters including PTC car- 
rier frequency, demodulation characteristics, and sub- 
channel PIDs, from the acquired program specific informa- 
tion. Processor 60 uses this information in configuring units 60 
13, 15, 17 and decoder 100 elements to acquire selected 
sub-channel (SC) program content. 

The program specific information including MGT, CIT, 
EIT, and ETT data and associated descriptors acquired and 
collated by processor 60 incorporates advantageous features 65 
exemplified in the data formats presented in FIGS. 2-9. 
These features facilitate the identification, acquisition, 
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assembly and decoding of program channel content and 
associated program guide data by decoder 100 (FIG. 1). 
Processor 60 forms a MGT as exemplified by the data format 
of FIG. 2 by accessing and assembling the program specific 
information packets that are stored in the unit 60 internal 

memory. The MGT contains data identifiers e.g. PID ETT 

205 and PID_PG 210 (FIG. 2) enabling the assembly of the 
CIT, EIT and ETT tables. Processor 60 uses the MGT data 
identifiers to access and assemble the program specific 
information packets to form the CIT, EIT, and ETT data and 
associated descriptors. 

Processor 60 uses the acquired CIT channel map 
information, as exemplified in FIG. 3, to identify the packets 
comprising the sub-channel SC that the User selected to 
view. A user selects sub-channel SC for viewing by entering 
two program channel numbers via remote control unit 70 
and interface 65. Individual program channels are advanta- 
geously allocated both a first and a second identification 
number. The first identification number (a major number as 

indicated by bundle number 300 in FIG. 3) identifies the 

broadcast source and broadcaster channel brand number e.g. 
Fox 5™, Channel 13™. The first identification number 
indicates a broadcast source of a program or service and may 
be independent of the RF channel on which the program is 
broadcast. However, in other embodiments the first identi- 
fication number may be associated with a broadcast RF 
channel or be associated with other program characteristics 
such as a program category or theme e.g. movies. The 
second identification number (a minor number as indicated 

by channel number in_bundle 305 in FIG. 3) identifies a 

sub-channel corresponding to a specific service within a 
group of services provided by a broadcaster. The first and 
second identification numbers in conjunction identify a 
particular service as a sub-channel provided by a specific 
broadcaster. Although, the selected sub-channel SC may 
occupy an RF bandwidth within an encompassing channel 
spectrum associated with the broadcast source, neither the 
first or second identification numbers are associated with 
such a spectrum. However, this association may be made in 
an alternative embodiment. This dual numbering system 
enables a broadcaster to retain channel brand identity across 
a range of dynamically allocable broadcast sub-channels. 

The dual program channel identification numbers used to 
select sub-channel SC may be entered by the user in a 
variety of ways. These may include using remote unit 70 to 
select sub-channel SC from within a hierarchical menu 
system displaying program channel selections in a program 
guide or by simple sequential number entry via the unit 70 
keypad, for example. The channel selection system may also 
encompass the use of a different data entry device such as a 
keyboard or discrete switches, for example. Further, the data 
entry system also accommodates the entry of a single 
channel identification number as well as dual identification 
numbers. Upon detecting a channel selection completion 
command, processor 60 converts a single channel identifi- 
cation number entry into dual identification numbers. Pro- 
cessor 60 converts the single channel identification number 
to dual channel identification numbers in accordance with a 
predetermined conversion map. This conversion may also be 
performed using a predetermined and stored algorithm or 
formula. The derived dual identification numbers are used 
by processor 60 for packet identification, tuning and for 
identifying other decoder information in the manner previ- 
ously described as if both numbers had been entered by a 
user. 

Processor 60 uses the received program channel identifi- 
cation numbers 300 and 305 provided from remote control 



6,031 

7 

unit 70 via interface 65 to determine the PTC corresponding 
to the selected sub-channel SC from the CIT. Once the PTC 
number (item 315 in FIG. 3) is determined, processor 60 
(FIG. 1) configures units 13, 15, and 17 to receive the PTC 
for the selected sub-channel SC. The unique program sub- 5 
channel determined from the program channel identification 
numbers 300 and 305 may alternatively be termed a service 
or a virtual channel or a logical channel and the CIT may be 
deemed a virtual channel table. Further, as well as associ- 
ating a particular PTC with first and second sub-channel 10 
identification numbers 300 and 305 of selected sub-channel 
SC, the CIT also associates other parameters with SC. These 

parameters include (a) a channel id 320 for linking the 

selected sub-channel SC with program content information 

conveyed in the EITs, (b) a channel type indicator 325 15 

identifying whether the sub-channel data is, analog e.g. 
NTSC, digital video e.g. ATSC video or digital audio e.g. 

ATSC audio, (c) an ETM flag 330 indicating whether a text 

message is available for this sub-channel, (d) a channel 
name 340 and (e) a descriptor 335 e.g. a Service Location 20 
Descriptor as described later. 

Processor 60 advantageously determines program map 
information for the selected sub-channel SC from Service 
Location Descriptor (SLD) conveyed within the CIT. The 
SLD program map information is exemplified by the data 2 5 
format of FIG. 4. The SLD associates the selected sub- 
channel SC with packet identifiers, e.g. item 420, used to 
identify individual packetized datastreams that constitute the 
components of a program being transmitted on selected 
sub-channel SC. In addition, the SLD program map 30 
information, in conjunction with the CIT, maps the selected 
sub-channel SC to a program number 405, a PCR (Program 
Clock Reference) identifier 410, a language code indicator 
425, and a stream type identifier 415 identifying a stream as 
video, audio, control, auxiliary or private information, for 35 
example. 

The SLD program map information replicates informa- 
tion already present within the Program Map Table (PMT) 
segment of the MPEG compatible transport stream input to 
decoder 100. However, by incorporating the SLD within the 40 
CIT, the time required by decoder 100 to identify and 
acquire a program being transmitted on selected sub-channel 
SC is advantageously reduced. This is because the CIT and 
SLD provide formatted and linked information sufficient to 
enable processor 60 to directly configure and tune the 45 
system of FIG. 1 to receive the selected sub-channel SC. 
Specifically, the CIT and SLD directly associate individual 
first and second sub-channel identification numbers with the 
PIDs for identifying the datastreams that constitute a pro- 
gram being conveyed on this sub-channel. This enables 50 
processor 60 to configure the system of FIG. 1 to receive the 
selected sub-channel SC without acquiring and using the 
Program Map Table (PMT) information in the MPEG com- 
patible transport stream input to decoder 100. In addition, 
the data partitioning, data formatting and data repetition 55 
frequency characteristics of the CIT and SLD program map 
information m ay be determined independently of the 
requirements of MPEG PMT information. 

The packetized decoded transport stream input to decoder 
100 from unit 17 contains video, audio and data representing 60 
TV programs, for example, and also contains sub-picture 
data. The sub-picture data contains picture elements asso- 
ciated with programs and channels selectable by a user for 
viewing including program guides, display commands, 
subtitling, selectable menu options or other items, for 65 
example. As such, the sub-picture data includes the EIT 
containing descriptive lists of programs (events) receivable 
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on the sub-channels listed in the CIT and also contains the 
ETT containing text messages describing programs and 
program sub-channels. 

Processor 60 determines from the CIT and SLD the PIDs 
of the video, audio and sub-picture streams constituting the 
program being transmitted on selected sub-channel SC. 
Processor 22, matches the PIDs of incoming packets pro- 
vided by decoder 17 with PID values of the video, audio and 
sub-picture streams being transmitted on sub-channel SC. 
These PID values are pre-loaded in control registers within 
unit 22 by processor 60. In this manner, processor 22 
captures packets constituting the program transmitted on 
sub-channel SC and forms them into MPEG compatible 
video, audio and sub-picture streams for output to video 
decoder 25, audio decoder 35 and sub-picture processor 30 
respectively. The video and audio streams contain com- 
pressed video and audio data representing the selected 
sub-channel SC program content. The sub-picture data con- 
tains the EIT and ETT information associated with the 
sub-channel SC program content. 

Decoder 25 decodes and decompresses the MPEG com- 
patible packetized video data from unit 22 and provides 
decompressed program representative pixel data to NTSC 
encoder 45 via multiplexer 40. Similarly, audio processor 35 
decodes the packetized audio data from unit 22 and provides 
decoded and amplified audio data, synchronized with the 
associated decompressed video data, to device 55 for audio 
reproduction. Processor 30 decodes and decompresses sub- 
picture data received from unit 22. 

The sub-picture data decoded by processor 30 includes 
text messages (Extended Text Messages — ETMs) in an ETT 
in the exemplary data format presented in FIG. 5. The text 
messages conveyed in the ETT of FIG. 5 are advantageously 
partitioned into time periods of specified duration. The 
segmented text messages describe programs occurring in a 
period of specified duration and start time e.g. 3 hour blocks 
starting from 12 a.m., 3 p.m., 6 p.m. . . . etc. Indicators 
defining the duration and start time applicable to the con- 
veyed text messages are included in the MGT of FIG. 2 

(duration item 215 and application time item 220 of FIG. 

2 respectively). A text message (e.g. extended text 

message 505) is conveyed together with a text message 
identifier (ETM_id 510) in the format of FIG. 5. 

Decoder 100 (FIG. 1) is able to more efficiently acquire, 
process and store program descriptive text messages that are 
partitioned into time periods of specified duration than is 
possible in the absence of such segmentation. This is 
because segmented text messages exclude information 
occurring outside the specified time period and consequently 
are smaller than non-segmented text messages. Therefore, 
segmented text message data occupies less storage space and 
can be acquired and processed more quickly than larger data 
blocks of non-segmented data. Further, the data format of 
FIG. 5 allows a user to acquire text message data for a 
selected sub-channel SC or a group of selected program 
sub-channels. This allows the identification, acquisition and 
decoding of text message data by decoder 100 to be focused 
on the programs and sub-channels of interest to a user and 
reduces the acquisition of redundant text message informa- 
tion. 

A text message conveyed in an ETT may contain channel 
information or program (event) information. FIG. 6 shows 
an exemplary format for assigning a text message identifier 
ETM_id 510 of FIG. 5 that identifies the type of text 
message e.g. whether the text message contains channel 
information (item 610 of FIG. 6) or program information 
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(item 605 of FIG. 6). The text message identifier 510 (FIG. 
5) also identifies the source e.g. sub-channel to which the 
text message pertains. 

A text message 505 conveyed in the ETT of FIG. 5 is 
compressed and formatted according to the multiple com- 5 
pressed text string format of FIG. 7. The compressed text 
string format advantageously incorporates indicators facili- 
tating the identification and decoding of multiple com- 
pressed text strings by processor 30 in decoder 100 of FIG. 
1. Processor 30 decodes text string 505 (FIG. 5) received 10 
from unit 22 (FIG. 1) by determining the compression, 
coding and language characteristics of the text string from 
indicators 705, 710 and 715 (FIG. 7) respectively. 
Specifically, processor 30, operating in conjunction with 
processor 60, decompresses received text string 505 by 15 
applying a decompression function e.g. a Huffman decom- 
pression function, selected using indicator 705. Similarly, 
processor 30, decodes the received text string by applying a 
decoding function interpreting text characters according to a 
character code set selected using indicator 710 and a lan- 20 
guage code set selected using indicator 715. Further, pro- 
cessor 30 determines the number of text strings to be 
processed and the number of bytes in each text string from 
indicators 725 and 720 respectively. 

FIG. 8 shows an exemplary indicator definition for com- 25 
pression indicator 705 within the multiple compressed text 
string format of FIG. 7. It is to be noted that compression 
indicator 705 may indicate that no compression function is 
employed within a text string. In this case, processor 30 does 
not apply a decompression function to the text string 
received from unit 22. FIG. 9 shows an exemplary indicator 
definition for coding indicator 710 within the multiple 
compressed text string format of FIG. 7. 

Processor 30 assembles and formats the decoded and 
decompressed text string elements of text string 505 (FIG. 5) 
to form a decoded text string for output to On-Screen 
Display (OSD) and graphics generator 37 (FIG. 1). Unit 37 
interprets and formats the text string character data from unit 
30 and generates formatted pixel mapped text and graphics 4Q 
for presentation on unit 50. The formatted pixel mapped text 
and graphics data may represent a program guide or other 
type of menu or user interface for subsequent display on unit 
50. Unit 37 also processes EIT, ETT and other information 
to generate pixel mapped data representing, subtitling, con- 45 
trol and information menu displays including selectable 
menu options, and other items, for presentation on unit 50. 
The control and information displays enable function selec- 
tion and entry of device operating parameters for User 
operation of decoder 100. 5Q 

The text and graphics produced by OSD generator 37 are 
generated in the form of overlay pixel map data under 
direction of processor 60. The overlay pixel map data from 
unit 37 is combined and synchronized with the decom- 
pressed pixel representative data from MPEG decoder 25 in 55 
encoder 45 via multiplexer 40 under direction of processor 
60. Combined pixel map data representing a video program 
on sub-channel SC together with associated sub-picture text 
message data is encoded by NTSC encoder 45 and output to 
device 50 for display. 60 

In a storage mode of the system of FIG. 1, the corrected 
output data from unit 17 is processed by decoder 100 to 
provide an MPEG compatible datastream for storage. In this 
mode, a program is selected for storage by a user via remote 
unit 70 and interface 65. Processor 22, in conjunction with 65 
processor 60 forms condensed program specific information 
including MGT, CIT, EIT and ETT data and descriptors 
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containing the advantageous features previously described. 
The condensed program specific information supports 
decoding of the program selected for storage but excludes 
unrelated information. Processor 60, in conjunction with 
processor 22 forms a composite MPEG compatible datas- 
tream containing packetized content data of the selected 
program and associated condensed program specific infor- 
mation. The composite datastream is output to storage 
interface 95. 

Storage interface 95 buffers the composite datastream to 
reduce gaps and bit rate variation in the data. The resultant 
buffered data is processed by storage device 90 to be suitable 
for storage on medium 105. Storage device 90 encodes the 
buffered datastream from interface 95 using known error 
encoding techniques such as channel coding, interleaving 
and Reed Solomon encoding to produce an encoded datas- 
tream suitable for storage. Unit 90 stores the resultant 
encoded datastream incorporating the condensed program 
specific information on medium 105. 

FIG. 10 shows a method for generating program specific 
information including MGT, CIT, EIT and ETT data and 
descriptors containing the advantageous features previously 
described. The method may be employed at an encoder for 
broadcasting video data such as the data received by antenna 
10 of FIG. 1 or the method may be employed within a 
decoder unit such as within processor 60 of FIG. 1. 

Following the start at step 800 of FIG. 10, a CIT is 
generated in step 810. The CIT contains sub-channel and 
program identification information enabling acquisition of 
available broadcast programs and sub-channels. The CIT 
incorporates first and second sub-channel identification 
numbers and an SLD containing packet identifiers for iden- 
tifying individual packetized datastreams that constitute 
individual programs to be transmitted on particular sub- 
channels. The generated CIT also incorporates items linked 
to listed program sub-channels including a program number, 
a PCR (Program Clock Reference) identifier, a language 
code indicator, and a stream type identifier, as previously 
described in connection with FIG. 1. 

In step 815, an EIT is generated containing program guide 
information including descriptive lists of programs (events) 
receivable on the sub-channels listed in the CIT. In step 820, 
an ETT is generated containing text messages describing 
programs, for example. Each text message is partitioned into 
time periods of specified duration. The duration and appli- 
cation time of the segmented text message data is also 
defined by indicators in the ETT itself. The text message 
data is encoded and compressed according to known tech- 
niques and conveyed in the ETT along with indicators 
defining the compression, coding and language characteris- 
tics employed. The ETT is also generated to include indi- 
cators defining the number of text strings to be processed 
and the number of bytes in each text string. In step 822 an 
MGT is generated containing data identifiers enabling the 
identification and assembly of CIT, EIT and ETT informa- 
tion. The MGT also conveys table size information for the 
previously generated CIT, EIT and ETT. 

In step 825, program specific information is formed 
including the MGT, CIT, EIT and ETT data and descriptors 
generated in steps 805-822. In step 830, the program 
specific information together with video and audio program 
representative components for multiple sub-channels is for- 
matted into a transport stream for output. In step 835, the 
output transport stream is further processed to be suitable for 
transmission to another device such as a receiver, video 
server, or storage device for recording on a storage medium, 
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for example. The processes performed in step 835 include 
known encoding functions such as data compression Reed- 
Solomon encoding, interleaving, scrambling, trellis 
encoding, and carrier modulation. The process is complete 
and terminates at step 840. In the process of FIG. 10, 5 
multiple CIT, EIT and ETT tables may be formed and 
incorporated in the program specific information in order to 
accommodate expanded numbers of sub-channels. 

The architecture of FIG. 1 is not exclusive. Other archi- 
tectures may be derived in accordance with the principles of 10 
the invention to accomplish the same objectives. Further, the 
functions of the elements of decoder 100 of FIG. 1 and the 
process steps of FIG. 10 may be implemented in whole or in 
part within the programmed instructions of a microproces- 
sor. In addition, the principles of the invention apply to any 15 
form of MPEG or non-MPEG compatible electronic pro- 
gram guide. Adatastream formed according to the invention 
principles may b e used in a variety of applications including 
video server or PC type communication via telephone lines, 
for example. A program datastream with one or more 20 
components of video, audio and data formed to incorporate 
program specific information according to invention prin- 
ciples may be recorded on a storage medium and transmitted 
or re-broadcast to other servers, PCs or receivers. Further, 
any reference herein to "bandwidth" is to be interpreted 25 
expansively to include bit rate capacity and is not limited to 
a frequency spectrum, for example. 

What is claimed is: 

1. Apparatus for decoding packetized program informa- 
tion containing multiple text strings associated with a 30 
program, comprising: 

means for determining from a first indicator in said 
packetized program information a type of coding and 
compression employed in encoding a first text string; 

means for decoding said first text string with a decoding 35 
function selected in accordance with said determined 
type of coding; and 

means for assembling decoded text string elements to 
form an output text string. 

2. Apparatus according to claim 1, wherein 
said means for decoding comprises means for decom- 
pressing said first text string with a decompression 
function selected in accordance with said type of com- 
pression. 

3. Apparatus according to claim 1, wherein 
said first indicator indicates that no compression function 

is used in encoding said first text string, and 
said means for decoding comprises means for interpreting 
codes in said first text string to produce text characters. 

4. Apparatus according to claim 1, including 
means for determining from a second indicator in said 

packetized program information a language type used 
in said first text string. 

5. Apparatus according to claim 4, including 55 
means for decoding said decoded first text string with a 

decoding function selected in accordance with said 
determined language type. 

6. Apparatus according to claim 1, including 

means for determining from a second indicator in said 60 
packetized program information the number of text 
strings to be decoded. 

7. Apparatus according to claim 1, including 

means for determining from a text mode coding indicator 
in said packetized program information a type of char- 65 
acter interpretation to be used in interpreting decoded 
text. 
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8. Apparatus according to claim 1, including 

means for determining from a second indicator in said 
packetized program information the number of text 
bytes in a text string to be decoded. 

9. Apparatus according to claim 1, wherein 

said decoded text string represents at least one of a) 
program or channel descriptive information, b) a broad- 
cast channel name, c) geographical region information, 
d) program content rating information, e) program or 
channel map table information, f) program or event 
table description information, and g) geographical rat- 
ing region table information. 

10. A storage medium containing MPEG compatible 
digital data representing video information comprising: 

a packetized video program; and 
information containing, 

(a) multiple text strings associated with said packetized 
video program, 

(b) a first indicator for indicating a type of coding 
employed in encoding a first text string, said first 
indicator being suitable for use in selecting a decom- 
pression function to be used in decoding said first 
text string; and 

(c) information suitable for use in assembling decoded 
text string elements to form an output text string. 

11. A storage medium according to claim 10, wherein 
said first indicator also indicates that no decompression 

function is to be used in decoding said first text string. 

12. Apparatus for generating program specific informa- 
tion suitable for inclusion in packetized video program 
information, said program specific information including 
multiple text strings associated with a video program, said 
apparatus comprising: 

means for forming text string decoding information for 
decoding multiple text strings, said decoding informa- 
tion including, 

(a) a first indicator indicating a type of compression 
employed in encoding a first text string for selecting 
a decoding function to be used in decoding said first 
text string; and 

(b) information suitable for assembling decoded text 
string elements to form a decoded text string; and 

means for incorporating said text string decoding infor- 
mation into program specific information for output. 

13. Apparatus according to claim 12, wherein 

said first indicator indicates that no decompression func- 
tion is to be used in decoding said first text string. 

14. Apparatus according to claim 12, wherein said text 
string decoding information includes 

a language type indicator indicating a language used in 
said first text string. 

15. Apparatus according to claim 12, wherein said text 
string decoding information includes 

a second indicator indicating a number of text strings to 
be decoded. 

16. Apparatus according to claim 12, wherein said text 
string decoding information includes 

a text mode coding indicator indicating a type of character 
interpretation to be used in interpreting decoded text. 

17. Apparatus according to claim 12, wherein said text 
string decoding information includes 

a second indicator indicating a number of text bytes in a 
text string to be decoded. 

18. Apparatus according to claim 12, wherein 

said first text string represents at least one of a) program 
or channel descriptive information, b) a broadcast 
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channel name, c) geographical region information, d) 
program content rating information, e) program or 
channel map table information, f) program or event 
table description information, and g) geographical rat- 
ing region table information. 5 

19. A method for decoding packetized video program 
information containing multiple text strings associated with 
a program, comprising the steps of: 

determining from a first indicator in said packetized video 

program information a type of coding employed in 10 

encoding a first text string; 
decompressing said first text string with a decompression 

function selected in accordance with said determined 

type of compression; and 
assembling decoded text string elements to form an output 

text string. 

20. A method for generating program specific information 
suitable for inclusion in packetized video program 
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information, said program specific information including 
multiple text strings associated with a video program, said 
method comprising the steps of: 

forming text string decoding information for decoding 
multiple text strings, said information including, 

(a) a first indicator indicating a type of compression 
employed in encoding a first text string for selecting 
a decompression function to be used in decoding said 
first text string; and 

(b) information suitable for use in assembling decoded 
text string elements to form a decoded text string; 
and 

incorporating said text string decoding information into 
program specific information for output. 
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Several different methods exist, when conducting a 

METHOD AND SYSTEM FOR MONITORING test market in a limited geographic area, to select those 

TELEVISION VIEWING households that will be exposed to a special television 

signal and to monitor the number of exposures to the 

This is a continuation of copending application Ser. 5 signal. To expose only those selected panelists to the 

No. 07/532,030 filed on Jun. 1, 1990, now abandoned. special television signal, such as a commercial, the sig- 

_ nal is inserted into regular programming and transmit- 
BACKGROUND OF THE INVENTION ted to selected households. 
This invention relates generally to an improved An old technique used in test marketing is described 
method and apparatus for identifying television broad- 10 in U.S. Pat. No. 3,366,731, issued Jan. 30, 1968 to Ed- 
cast programs as they are received by a television re- ward Wallerstein for Television Distribution System 
ceiver in the household. This invention is particularly Permitting Program Substitution for Selected Viewers, 
useful in the field of test marketing but is not limited In this system two cables originating from the same 
thereto. Test marketing allows businesses to test and source go out to different groups of households. With 
experiment with a marketing strategy in a limited geo- 15 this system configuration different advertisements can 
graphic area before committing to a full launch of the be inserted on each cable and transmitted to the differ- 
proposed marketing plan. Test markets are usually con- ent groups. A shortcoming of this system is that there is 
ducted by monitoring the behavior of a panel of house- n0 automatic recording of the event when the television 
holds in a limited geographical area. Very precise de- 1S tuned t0 a channel on which an advertisement has 
mographic information is maintained on the households 20 been sen * out To S et an estimate of the panelists expo- 
in the panel. The research generally consists of monitor- su » t0 the substituted commercial the researcher must 
ing the behavior of a panel of households both before on program ratmgs and audience projections for 
and after one or more variables in the environment have the P r °gram during which the substitute commercial 
been changed. The research also consists of correlating ^ wa f ransmi e * ^ 
the panelists' behavior with exposure to television com- 25 JT I ^f^TT* £ 
mercials and other forms of advertisement. An example £.S »at No. 3 639 686, issued Feb. 1, 1972 to Harold 
of one type of relationship that is of particular interest f talker and Ira Kamen for Television Receiver Cut- 
* J ^ - . A - , A . f . In Device. In this system an auxiliary television signal is 

to the researcher is the relationship between the pur- , o . , * + u a * *i, 3 V 

c i** j • • i ■ ■ broadcast throughout a broadcast area with a particular 

chasing benavior ot panelists ana viewing or television 3Q control identifying the class of 

viewers that is to 

commercials ^b> ^panelists. Two types of data are re- be reached b ^ Revision signal. This sys- 

quired to study this ;relationsmp. First is the data rel^ tem uses M decoders which ^ ^ ^ ^ 

to the panelists' behavior, such as their purchasing pat- gi ^ ^ certain conditions when the receiv ^ r re . 

terns of products or services. The second type of data cdves a particular address si ^ identifying the respec . 

that is momtored is the number of exposures to a partic- 35 tiye receivers ^ being m the class to which the si j i$ 

ular commercial or advertisement that the panelists to be transmitted. A limitation of the system is that it 

receive. Sometimes the researcher monitors two or does not record the event ^ tQ whether or not the 

more panels of households at the same tune. This tech- special television signal was displayed on the television, 
nique permits inter group comparisons to be made as An improvement on the previous two systems is illus- 

each group is exposed to either different types of com- 40 trated m UtS . Pat. No. 4,331,974, issued May 25, 1982 to 

mercials or advertisements and/or different amounts of Cogswell et al. for Cable Television With Controlled 

exposure to these stimuli. The groups may be referred Signal Substitution and U.S. Pat. No. 4,331,973, issued 

to as the control group and the test group, M ay 25, 1982 to Eskin et al. These patents describe a 

DESCRIPTION OF THE PRIOR ART dynamic cut in device, so called because the household 

45 panels may be individually selected for each market test 
Collection of the data relating to the products pur- conducted by the researchers. A major problem with 
chased by the cooperating panelists can be done by one tnese sophisticated methods is that at least one addi- 
of several well known methods, some of which are t ional channel is required to transmit the substitute tele- 
described in some of the prior art. One such method vision signal. With the proliferation of new cable chan- 
utilized in the past has been to have the cooperating 50 nels, spare channels are scarce, difficult to obtain and 
panelists manually maintain a diary of their purchases. therefore expensive. The necessity for this extra chan- 
Another method as described in U.S. Pat No. 4,331,973 n el in some of the prior art increases the total cost of 
issued May 25, 1982 to Eskin et al. for a Panelist Re- conducting the test market as the extra channel has to 
sponse Scanning System requires the cooperation of be leased from the cable operator. Another problem is 
retailers in the test area. Panelists who present their 55 that although the system does record when a panelist 
unique identification card to the cashier at the point of television receiver is turned on and the channel selected 
purchase will automatically have their purchases re- by the respective viewer, this vast quantity of informa- 
corded. The purchases are recorded in stores where tion must be mapped onto a master schedule or some 
universal product code automated check-outs are avail- other similar procedure must be performed to deter- 
able and the collected information is retained in the 60 mine if the substitute program was displayed on the 
store's computer and transferred to the market research panelist's television receiver. 

firm's database at a convenient time. Another system as Yet another system is described in U.S. Pat. No. 

set forth in U.S. Pat. No. 4,658,290 issued on Apr. 14, 4,658,290 issued to McKenna et al. describes a house- 

1987, to McKenna et al. permits the panelists to record hold data gathering system that utilizes a simplex re- 

their purchases in the house through the use of a univer- 65 ceiver which permits dynamic allocation so that televi- 

sal product code reader. The information collected can sion signal substitution may be performed. Similar to 

be stored in a collection unit in the house and subse- most of the other systems described, this one also re- 

quently transferred to a central location. quires the alternate signal to be transmitted from the 
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cable head end and down channels normally not used „„„ „ „ _ 

for entertainment. BRIEF DESCRIPTION OF THE DRAWINGS 

GTTx,rx,r Aovnc tuc TKn/t3VTT'T/->xT FIG - 1 is a b l° ck diagram of the system. 

SUMMARY OF THE INVENTION FIG. la is a block diagram of a master-slave PMU 

One object of the present invention is to provide a 5 subsystem, 

novel automatic method and apparatus for identifying FIG. 2 is a block diagram of the Program Monitoring 

broadcast television programs and commercials as they Unit (PMU). 

are viewed by selected households. FIG. 2a is a diagram showing a view of fields 31, 32 

Another object of the present invention is to provide of frame 3. 

an improved in-house commercial monitoring system so 10 FIG. 2b shows the waveform of line 21, field 31 of the 

that when it is combined with a split cable system and NTSC television signal. 

any of the known techniques for collecting product FIGS. 3a and 3b comprise a circuit diagram for the 

purchase data, it provides a new and improved cost decoder shown as a block in FIG. 2. 

efficient means of conducting test marketing. FIG - 4 is a key diagram for FIGS. Aa and 4£. 

Another object of the present invention is to provide 15 FIG - 4(2 is a partial flow chart for the software that 

an improved method of commercial monitoring that assembles a paragraph of closed captioning data, 

may be incorporated into any of the known methods of FIG * 4b is the continuation of FIG. 4c. 

signal substitution and reduce the amount of data that FIG * 5 is a flow chart for the software that seeks a 

previously needed to be collected. match for a paragraph of received caption data in the 

These and other objects are achieved by monitoring 20 ca P tion library, 

in the panelist's household the programs and commer- FIG ' 6 1S a flow chart for the ste P s required to make 

cials on the channel to which the viewer is tuned. One an entry t0 the ca P tl0n library, 

method of monitoring using a central computer system FIG * 7 1S a block dia S rain of tables contained in and 

is described in U.S. Pat. No. 4,857,999 issued Aug. 15, re P orts grated by the central computer of the sys- 

1989, for a Video Monitoring System and assigned to 25 tem * 

the assignee of the present invention. DETAILED DESCRIPTION 

The method of the present invention similarly moni- . , , , , ,. 

tors line 21 of field 1 of the television signal to extract FI f - 1 show * a B bl ° ck diagram illustratmg a program 

strings of characters. These character strings are com- w m0 f ° mg ™* f interconnected with other compo- 

pared to a library of preselected character strings which 30 Y? ^ , t market /y s [ em 2 

*j* J * , * v which includes commercial substitution. Preferablv, a 

are stored m a memory located in a remote panelist's «i„ M i: + „ o -a a y ^aviy, <x 

^ i* u -* r* i/ - u * ■** ^ c plurality of units 8 are provided, appropriately located 

household umt after having been transmitted from a L*u^uL^^^^ Q r,^ + u n u t. ^ 

. lt +■ + * u * * • *. j * i m tne houses of panelists or the like who have agreed to 

central location to the umt via the non-dedicated tele- participate m th £ L ^ tdevjsion si j ^ 

phone line. If a match of character strings is obtained, 35 from a cable teleyision head end g fa * ransmitted t0 
he occurrence of the event and the time it occurred are a subscriber via a conventiona i transmission line 3. The 
logged in the umt s memory. This data may be transmit- signal is directed t0 a ^ converter 6 which fa used b 
ted at an appropnate time to a central location via a the householder t0 select the te i ev ision channel that is 
non-dedicated telephone line. to be viewed on a television receiver or set 10. The 

1 lie present invention is superior to the existing tech- 40 output 7 of the cable converter 

6 is normally fixed on 

niquesusedmpanehstehou^holdsasitwUlbeableto one VHF television channel such as channel three, 
identify a plurality of predetermined commercials as Output 7 of the cable converter 6 is connected to the 
they are viewed in the house and record the occurrence p r0 gram monitoring unit 8 where signal processing and 
of such events. This is an improvement over the prior data collection functions are performed, as explained in 
art as it eliminates the need to monitor the channels and 45 more detail latert ^ channel three si ^ Qn line ? is 
times at which the commercials were broadcast on the pre ferably passed through the program monitoring unit 
cable so that the commercials viewed by panelists can $ so that it can be viewed on the panelist's television set 
be determined from the television set tuning data that is 10 via line 9. A second output path or telephone line 11 
collected in the house. A further improvement over the from the program monitoring unit 8 is connected to a 
prior art is that the present mvention reduces the 50 conventional telephone jack 12 through which outgo- 
amount of information that must be stored by the moni- mg and incoming telephone calls are linked to the panel- 
tormg umt located in the panelist's house. This improve- i st 's house with appropriate wiring and the like inter- 
ment is of particular use but not limited to an area of connecting telephone receivers 13 in the panelist's 
research known as "share of voice." In this type of house with a conventional switched telephone network 
research the advertiser is interested in comparing the 55 14. A household telephone line 25 is used to provide a 
number of exposures a panelist has received of a partic- communication channel from the program monitoring 
ular advertisement relative to exposures to other adver- unit 8 through network 14 to a central computer 15. 
tisements for similar products or services. The present Boundary 4 encloses those elements of system 2 in a 
invention is appropriate for this task as it can record particular household and indicates elements to be repli- 
when and which one of a plurality of preselected adver- 60 cated for multi-household applications, 
tisements was viewed by the panelist. Unlike the prior Referring also now to FIG. 2, the program monitor- 
art the present invention can record the occurrence of ing unit or PMU 8 contains a character string table 
preselected events and there is no need for the re- stored in a memory 20. Each entry in this table consists 
searcher to monitor all channels to identify on what of a character string and a shorter unique program in- 
channel and at what time one of the commercials of 65 dentification code. The program monitoring unit 8 pro- 
interest occurred. This was necessary in prior art sys- cesses the television signal on line 7 to extract character 
terns which only record whether the television receiver strings that are embedded in the the television signal 
was on and to what channel it was tuned. and then searches the character string table for a match. 
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When the program monitoring unit is first installed in a 15. During a communication session with the PMU 8, 

household, the table is initialized with the character the central computer 15 may recover any data that has 

strings and program identification codes for the com- been collected by the PMU 8 and may update the char- 

mercials that it will search for. Whenever the program acter string table in RAM 20. 

monitoring unit communicates with the central site, the 5 The central computer 15 recovers the contents of the 

contents of this table can be changed. event log from a PMU 8 during a communication ses- 

In accordance with this embodiment, memory 20 also sion. Each event recovered from a household PMU 8 

store data as to which commercials have been viewed includes the program identification code and corre- 

by the panelist. Periodically the program monitoring sponding date and time values. The central computer 15 

unit 8 will use the household telephone line 25 to "dial- 10 maintains a database that includes household identifica- 

up" the central computer 15. On establishing appropri- tion numbers and the program identification numbers 

ate telephone communications with the panelist's pro- for each commercial that each household viewed along 

gram monitoring unit 8, the stored data is transmitted with the corresponding date and time at which that 

via the public switched telephone network 14 to the respective commercial was viewed, 

central computer 15. In addition to extracting data from 15 The description of system 2 to this point has de- 

the program monitoring unit 8 while the telephone scribed a situation in which only one television set is 

communication is active, the central computer 15 may monitored in a household. However, it is to be under- 

also download instructions and data to the program stood that the system can easily be expanded to deal 

monitoring unit 8 via the telephone line 25. with households with more than one television set. In 

The main components of the program monitoring 20 such event, each additional television set is equipped 
unit (PMU) 8 preferably includes an 8-bit microproces- with a program monitoring unit 8. At installation time, 
sor 19, ROM (read only memory) 26, an EEPROM the EEPROM 28 in each unit would be programmed 
(electrically erasable programmable read only memory) with a television set identification number unique to that 
28, a demodulator 17, a decoder 18 and a power supply household as well as the household identification num- 
23. The power supply 23 provides the required power 25 ber. During a communication session with each unit 8, 
for various components to function properly, and is the central computer would recover the household and 
connected through a transformer (not shown) to the television set identification numbers as well as the con- 
household's regular AC power source through lines 34. tents of the data event logs. 

Since each PMU 8 is unique to a particular house it An alternative method of handling multi-set houses 

contains an EEPROM 28 which is a non-volatile mem- 30 uses one master unit to handle all communications with 

ory that is used to store parameters that are specific to the central computer 15 and slave units to handle the 

the household. The information programmed into the data collection at each television set and which are able 

EEPROM 28 includes a unique household identifica- to communicate with the master unit, 

tion number and the telephone numbers for the PMU 8 To provide for this feature the PMU has a MasterA 

to use to "dial-up" the central computer 15. 35 Slave Communication block 24 to facilitate the connec- 

The PMU also contains a signal splitter 16 to which tion of the master unit to a plurality of slave units, 

the signal from the household's cable converter 6 is FIG. la shows a block diagram of a master PMU 8 

directed. There are two output paths from the splitter connected to two slave PMUs 8a and 86. Each slave 

16; the first path 9 goes directly to the television re- PMU So, b is basically the same as the master PMU 8, 

ceiver 10 in the household so that the viewer watches 40 the only difference being that the slave PMUs $a,b need 

the television channel that was originally selected on not contain a modem to facilitate communication with 

the cable converter 6. Unlike some previous systems the the central computer 15 via the telephone line 11. The 

present invention utilizes a conventional cable con- slave PMUs 8a, b communicate with the central com- 

verter 6 that is normally found in households. The sec- puter 15 through line 11a to the master PMU 8 and then 

ond output 27 of the splitter 16 is directed to demodula- 45 through the telephone line 11 connected to the modem 

tor 17. The demodulated signal on line 29 is then sent to 22 in the master PMU 8. The master and slave units 

the decoder 18. Decoder 18 produces the character 8-8o,& preferably communicate over dedicated wiring 

strings that are encoded in the television signal. A pre- 11a in the panelist's household that is installed at the 

ferred method used to decode the character string from same time as the PUMs 8-8a,6. Whenever the central 

the demodulated television signal is described in U.S. 50 computer communicates with the household it does so 

Pat. No. 4,857,999. through the master PMU 8. Any information sent to the 

The character string is directed to the microproces- master PMU 8 to update the character string table is 

sor 19 via path 30. Microprocessor 19 compares this automatically forwarded from the master unit 8 to the 

character string to strings contained in a character slave units 8a, 6. Periodically the master unit 8 interro- 

string table in the random access memory (RAM) 20. If 55 gates each of the slave units to collect any event log 

a match of character strings is detected, the present time data that is present. The data from each of the slave 

on a system clock 41 and a program identification code units 8a, b is maintained in separate memory areas in the 

for the commercial are stored in an event log in the master unit RAM 20. When the central computer 15 

RAM 20. If no match is found the system ignores the communicates with the master unit 8 it will collect the 

decoded character string and no new data is stored in 60 data event logs of the slave units 8a, b along with the 

the event log. Each time a character string is produced event log of the master unit 8. 

by the decoder 18, the previously described comparison The description to this point has described a system 2 

procedure takes place. in which the remote PMU 8 in the household has 

PMU 8 also preferably includes a modem 22 by searched for specific character strings, each associated 

which it communicates with the central computer 15 65 with a specific television commercial. However, in a 

via the regular telephone lines 25. Each PMU 8 is as- more general application, the system could be used to 

signed a time at which it uses the household telephone identify all the commercials or all the programs includ- 

line to establish a connection with the central computer ing commercials that are viewed in the household. In 
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this case, the PMU 8 would store all the character outputs at pins 7 and 5, respectively. Ul further has a 0. 1 
strings that were decoded from the received television uF capacitor C6 and a 470K resistor R5 connected to 
signal. These character strings would be returned to the pin 6. Ul still further has a 0.1 uF noise suppression 
central computer 15 during a normal communication capacitor C7 connected to its power supply input pin 8. 
session. The central computer would then assign the 5 The FIELD output of Ul at pin 7 is connected to a 
appropriate program identification codes. digital logic inverter U9A, which is preferably formed 
Before proceeding with the description, some back- from a type 74HC04 hex inverter. The output of in- 
ground on the closed captioning signal is required. The verter U9A is passed through a 330 pF capacitor C9 to 
reader is directed to the referenced PBS Report No. input pin 9 of U7, which is a HC4O103 type integrated 
E-7709-C for a complete specification of the closed 10 circuit counter available from Signetics. Diode Dl, 
captioning signal. The NTSC television signal is com- along with all other diodes in FIGS. 3a and 3b may be 
prised of 30 picture frames per second with 525 scan a 1N4148 type. Output pin 5 from Ul is connected to 
lines per frame. Referring now to FIG. 2a, first and the input of another inverter U9B. Output pin 2 of in- 
second fields 31, 32 of a frame 33 may be seen. Scan line verter U9B is connected to the gate G of Ql and input 
21 in field 31 of frame 33 is reserved for the closed 15 pin 3 of inverter U9C. Output pin 4 of inverter U9C is 
captioning signal as described in the FCC Rules and connected through a 2K2 resistor R6 to the clock input 
Regulations Title 47, Part 73, Section 682. The wave- pin 1 of U7 and through a diode D2 to the not Q output 
form of this signal 37 is shown in FIG. 2b as depicted in pin 8 of U4. U4 is preferably a type HC74 integrated 
the FCC Rules and Regulations Title 47, Part 73, Sec- circuit available from Signetics. A 3K3 resistor R7 is 
tion 699 which is hereby expressly incorporated by 20 connected from the power supply to the input pin 9 of 
reference herein. As depicted in FIG. 2b, line 21 con- U7. 

sists of a horizontal sync pulse 38, followed by the color The source S of Ql is connected through a IK resis- 

burst 40, followed by 7 cycles of clock run-in 42 and tor R8 to the non-inverting input pin 5 of a type LM358 

then a two-character wide data window 44 for closed integrated circuit operational amplifier, available from 

captioning information. Data may be transmitted in the 25 National Semiconductor. A 0.1 uF capacitor C10 is 

window as a pair of characters every 33.3 milliseconds. connected between the non-inverting input pin 5 and 

The maximum data rate is 60 characters per second. circuit common. The output pin 7 of U6 is connected 

The purpose of the decoder 18 is to process the com- through a resistive network of a 470 ohm resistor R14 

posite video signal and extract the data in the window and a 12K resistor R13 shunted by a 0.1 uF capacitor 

44 which may include up to two characters of closed 30 C13 and passing to the non-inverting input pin 4 of 

captioning information from each occurrence of line 21. U8A, which is preferably a type LM319 voltage com- 

This module contains two sections — the first extracts parator. Output pin 6 of U3 is also connected through a 

line 21 signal or waveform 37 from field 31 of each IK resistor R9 and across a 100 pF capacitor CI 1 to the 

frame 33 of the composite video signal and the second non-inverting input pin 3 of U5, which is preferably a 

extracts character data from each occurrence of line 21 35 LM6361 type operational amplifier. The output pin 6 of 

if characters are present in data window 44. U5 is connected through a diode D3 through a resistive 

The circuitry of the signal processing module 48 is network of a 150K resistor R10, a 51 ohm resistor Rll, 

shown in FIGS. 3a and 36. FIG. 3a shows the circuit and a 10K resistor R12, connected to the non-inverting 

that extracts signal 37 from line 21, field 31 of frame 33 input pin 4 of USA. A 1.8 nF capacitor C12 is con- 

and FIG. 3b shows the circuit that extracts characters 40 nected between resistors Rll and R12. 

from data window 44 of signal 37. Positive feedback for U8A is provided by a 560K 

The function of the circuitry shown in FIG. 3a is to ohm resistor R16, while diode D4 and a 470 ohm resis- 

process the composite NTSC television signal, separate tor R15 are connected in the output pull-up path of 

the line 21 signal 37 from the complete NTSC signal U8A. A pair of inverters U9D and U9E formed from 

and convert it into two digital signals, DR and DW. 45 the hex inverter U9 are connected in parallel to drive 

Signal DR is a line 21 gate signal and signal DW is a line output DR from the TC output of U7 at pin 14. The 

21 data signal. output of U8A is connected to a digital logic inverter 
The video is input at the connector Jl. The video U9F to provide output signal DW. Ul can accurately 

signal passes across a 1.8 nf capacitor CI and through a identify the start of a new field and has field index and 

22 uF capacitor C2 to a 45 microhenry inductor LI in a 50 back porch gate outputs. Signal DW is a bit stream of 
resistive ladder network having a 100K resistor Rl and the clock run-in pulses 22 and the data bits in window 
a IK resistor R2. The signal is then passed across a 3.3 24. Signal DR is active (high) only when line 21 in field 
nF capacitor C3 and through a IK resistor R3 to a 100 1 is being processed. 

pF capacitor C4 and into the non-inverting input pin 3 The operation of this portion of the circuit is as fol- 

of a type SE5534 operational amplifier U2, available 55 lows. Signal DR is normally low and goes high only 

from Signetics. Amplifier U2 is connected in a unity when NTSC line 21 is present. Signal DW goes active 

gain non-inverting configuration having an output at only during NTSC line 21. Line 21 is identified by Ul, 

pin 6 feeding a O.luF capacitor C5 which passes the AC U4 and U7. Ul accepts the composite video signal as 

component of this signal to the non-inverting input of input on pin 2 and produces output signals at pins 7 and 

another type SE5534 operational amplifier U3, also 60 5. The FIELD signal at pin 7 of Ul is high (+5 volts) 

connected as a unity gain non-inverting follower. Out- when NTSC field 1 is being received and low (0 volts) 

put pin 6 of U3 is connected to the drain D of a 2N7000 when NTSC field 2 is being received. The BP signal 

FET transistor Ql. The signal at pin 3 of U3 is also from pin 5 of Ul is a 4.8 usee pulse that occurs in the 

connected through a 470 ohm resistor R4, across a 1.8 middle of the back porch 4S following the horizontal 

nF capacitor C8 and into pin 2 of an LM1881 type 65 sync pulse 38. Counter U7 is initialized by the FIELD 

integrated circuit, available from National Semiconduc- signal at the beginning of field 1 and is counted down by 

tor. Ul is used as a sync separator to identify the start of the pulses from BP. When line 21 is reached, pin 14 on 

a new field. Ul has field index and back porch gate U7 goes low for one scan line, thus creating the line 21 
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gate signal DR. The next pulse on BP causes pin 14 on Output enable signal lines EN1 and EN2 are similarly 

U7 to return to the high state which sets the flip flop U4 connected to connector P2. 

and terminates counting by U7 until the next frame. The The function of the circuitry shown in FIG. 36 is to 
signal pulse BP is also used to sample the video signal to process the signals DW and DR to load the serial bits of 
create a black reference level. When BP is active, it 5 the two characters into a register which can be accessed 
turns on Ql, allowing the black level of the back porch by a parallel read operation. Signal DW is active only 
25 to be sampled and stored on capacitor CIO. The peak during NTSC line 21. When it is active it is a digital 
value of the video of line 21 is stored on capacitor C12. logic waveform consisting of the 7 cycles of the clock 
The voltage difference between the voltages stored on run-in followed by one start bit and two 8 bit data char- 
C10 and C12 is divided by the resistors R13 and R12 to 10 acters. The rising edges of the clock run-in pulses trig- 
create a reference level that is about half way between ger two one shots U10 and U17. The function of the one 
the two levels. This reference level is applied to pin 4 of snot circuit U10 is to derive a normalized clock signal. 
U8A and the composite video signal is applied to pin 5 Tne normalized clock signal from pin 13 on U10 is used 
of U8A. U8A is a high speed comparator which, as a t0 energize the resonator XI which is tuned to the clock 
result of comparing the composite video signal to the 15 nm-fo signal frequency of 503.5 KHz. The resonator XI 
reference level will provide a digital logic signal at pin is squared up by the comparator U8B. Referring 
12. This signal is inverted by U9F to produce signal also t0 FIG * 2 > the P enod of th « dock run-in signal is 
DW. Signal DW is normally clamped high, but during L98 usec P er °y cle md the seven c y° les are followed by 
line 21 when DR goes high, signal DW is released and ?.972 usec ? f low sl S nal leveL ^ one shot fonned b V 
carries a digital logic waveform consisting of a digital 20 V } 7 ' s ^tnggerable and times out after the end of the 
representation of clock run in pulses 42 and data bits of resultmg m th ? se , ttm S of the fli P 
window 44 in line 21 flop U1L Settm S U11 unclamps the clock input on U18. 

Referring now to FIG. 3b, signals DW and DR are ne fl, da ^ ri 1 n f Q e ^5 0 w f be ' he sta * bit wWch ™ll 

processed to extract two characters for each occur- „ then f fhp flop U18. U18 

rence of line 21, field 31, containing closed captioned 25 an ? V1 * ™ d U16 The counter U14 is 

t_ * e- i ™i7 • j r j . . . c initialized with a value of 16 and is driven by the clock 

characters. Signal DW is delivered to the B mput of - v . ^ _ , 4 .. y ^ 

i. riMA j ttit t. c Li i. * iTom the resonator XI. The 16 data bits are subse- 

each of U10 and U17, which are preferably a one shot „ +1 , , , . + +u . 4 

* vi n- -u + • v + Tjw>n -i quently clocked into the shift registers. When the 

or monostable multivibrator circuit type HC123, avail- ^„ , ^ m ^ , . f. fTT1>1 . 

r 0 . * . TT - n u • * dio «a counter hits zero, the signal on pm 14 of U14 goes low 

able from Sixties. U10 has a 3K3 resistor R18, a 330 3Q wMch terminates ^ ^ ^ shift g registers 

pF capacitor C15, a 3K3 M U15, U16. After NTSC line 21, signal DR goes low. 

Tt^ ^ DR ^ the contents of the shift registers U15 

of U10), m addition to a 0 1 uF capacitor C16. U17 has ^ m6 afe ayailable tQ ^ micro rocessor 5 19f A ^ 

a 4K resistor R20 and a 1 nF capacitor C17. Ull and to . low transition of DR can be used an an 

U18 are preferably formed of a 74HC74 D-type flip flop 35 that the data is available m the shift re isters U15j U16 . 

available from Signetics. Diode D7 is connected to the ^ data can be read from the shift fe ^ sters Ulg ^ 

DW signal line through a 3K3 ^ resistor R21. Diode D5 is m6 one g bit character at a time by foiling the 

connected between pm 1 of U10 and pm 8 of U18. Gate chip enable signal lines EN1 md EN2 connected re . 

U12A is preferably formed of a 74HC86 type mtegrated S pectively to pin 13 of U15 and U16 as shown in FIG. 

circuit available from Signetics and couples the Q out- ^ 36< ^ fallillg edge of the signal DR can be used tQ 

put at pin 13 of U10 through a 33 pF capacitor C19 to generate an interrupt on each port of the interface 

a 503.5 kilohertz resonator XI which may be a model board Qn each occurrence of an interrupt, micro- 

503B as manufactured by Murata. Resonator XI con- processor 19 reads the characters from the shift regis- 

nects to a 0. 1 uF capacitor C21 and a network fonned of ters U15> XJ16 associated with the interrupt-generating 

a 220 pF capacitor C20, a 100K resistor R23, a IK 45 port md stores ^ characters as data in a buffer in 

resistor R27 and 10K resistors R25 and R26 to provide memory. Further processing of the data is controlled by 

a cleaned-up clock signal from pin 13 of U10 to both firmware in the PMU as shown in FIGS. 4 and 5. 

inputs of U8B, which is preferably a type LM319 volt- i t is t0 be understood that the closed captioning infor- 

age comparator with a 100K positive feedback resistor mation channel supports a caption mode and a text 

50 mode in both a primary and a secondary language. The 
The DR signal passes through a IK resistor R29 and caption mode text is recorded on a video tape along 
enables the output of U8B at pin 7 and fed to one input with the commercial and is automatically broadcast 
of U12B which is an inverter formed of a 74HC86 when the tape is played. When present, the text mode is 
integrated circuit. U14 is preferably a type HC40103 generated and transmitted by the broadcaster when the 
integrated circuit counter available from Signetics, and 55 channel is not being used to carry caption mode data, 
connected to operate as a divide-by-16 counter. The caption and text modes in both languages are time 
Counter U14 has a 0.1 uF capacitor C22. Diode D8 multiplexed into the one serial character channel. Con- 
couples the TC output from U14 pin 14 to pin 10 of trol code characters are used to switch the character 
U12B. The output of U12B at pin 8 is connected to the stream between caption mode and text mode and be- 
CLK inputs of U16, which is preferably a type HC595N 60 tween the two languages. 

8-bit shift register, available from Texas Instruments. The microprocessor 19 must separate the caption 
Signal DR is also coupled through a 330 pF capacitor mode characters from the remainder of the character 
C18, to diode D6 and into an input of U12C. The output stream. The characters in the closed captioning text are 
of U12C at pin 3 is connected to the R input (the reset organized into phrases and sentences complete with 
input) at pin 10 of U15 and U16 which are both a type 65 punctuation and control codes. In caption mode, the 
HC595N 8-bit shift registers. Signal DR is provided to control codes perform operations such as erasing the 
connector P2 through a 470 ohm resistor R30. The displayed captions, selecting the line on which the cap- 
outputs of U15 and U16 are connected to connector P2. tions are to be displayed, setting colors for the charac- 
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ters, and controlling scrolling of the captions on the 
television set. For the purposes of this system, the cap- 
tion text can be considered to be a series of paragraphs 
where a paragraph is the series of characters between 
two successive commands to clear the captions from the 5 
screen. The characters in a paragraph can be organized 
into phrases and sentences. 

The command to erase displayed captions occurs 
relatively frequently; typically at any significant scene 
change. Every commercial begins and ends with a com- 10 
mand to erase the displayed captions. Therefore, a com- 
mercial can include one or more paragraphs of caption 
text. Microprocessor 19 recognizes commercials by 
extracting the caption mode text from the continuing 
character stream, organizing this text into sensed para- 15 
graphs and then comparing each sensed paragraph to a 
library of stored paragraphs for the commercials that 
the system has been trained to recognize. Each stored 
paragraph in the library preferably has a corresponding 
commercial ID number. 

In one embodiment, sensed paragraphs are compared 
directly to stored paragraphs. In an alternative embodi- 
ment, the caption mode paragraphs are compressed by 
a data compression algorithm. The data compression 
algorithm processes the variable length string of ASCII 
characters that comprise the paragraph and produces a 
shorter and preferably unique string or key of encoded 
bytes. A number of algorithms are known to those 
skilled in the art; a preferred data compression algo- 3Q 
rithm is Adaptive Lempel-Ziv Coding, which may be 
found in an article by Terry Welch entitled "A Tech- 
nique For High Performance Data Compression/' pp. 
8-19 of Vol 7, No. 6, of IEEE Computer, June 1984. 
One alternative algorithm or technique which may be 35 
used is Huffman Encoding, which may be found in an 
article by Jonathan Amsterdam entitled "Data Com- 
pression with Huffman Coding," pp. 99-108 of Vol. 11, 
No. 5 of BYTE Magazine, May, 1986. A still further 
alternative is to use hash coding to form a key for data ^ 
"compression." While a hash code key is irreversible in 
the sense that the original data cannot be recovered 
from the key, reversibility is not necessary for the prac- 
tice of this invention. It is theoretically most desirable to 
have a one-to-one and only one-to-one correspondence 45 
between the original data and the key resulting from 
operation of the data compression algorithm on the 
original data. In other words, it is preferable to have one 
and only one set of original data correspond to a given 
key. Nevertheless, it is to be understood to be within the 50 
spirit and scope of this invention to use an algorithm 
having a less than ideal data-key correspondence, 
which, for example, can provide savings in operating 
speed, storage requirements or other practical consider- 
ations that outweigh the risk of error in using such an 55 
"imperfect" data compression algorithm. 

Returning to a preferred embodiment, both sensed 
and stored paragraphs are processed by a data compres- 
sion using adaptive Lempel-Ziv Coding to produce a 
unique multi-byte key. These keys can be stored in the 60 
library instead of the complete paragraph itself. The 
library in this case would include the multi-byte keys, 
each with a corresponding commercial ID number. 
When the system is identifying commercials, the sensed 
paragraphs (derived from the broadcast sources) are 65 
each put through the same algorithm or transform to 
produce a key which is then compared to the keys in the 
library. 



FIG. 4 is a flow chart for the operation that performs 
the task of reading the characters into the microproces- 
sor 19 and then forming the characters into paragraphs 
of caption mode text. This module is started by a higher 
level task and once started will continue to operate as an 
independent, interrupt driven task until cancelled by the 
task that initiated it. When the task is started at entry 
step 101 it acquires a pool of empty data buffers which 
are used to assemble the paragraphs and to transfer the 
completed paragraphs to the higher level task. At step 
102 the module 100 initializes itself, fetches an empty 
data buffer (the "active" buffer) from the pool, and 
defaults to a caption mode active condition. It then 
proceeds to step 103 where it enters a suspended condi- 
tion, waiting for an interrupt. When an interrupt occurs, 
the task proceeds to step 104 and reads the two charac- 
ters from the signal processing module 8. At step 105, a 
test is made to determine if the secondary language bit 
is set; and if it is the characters are ignored and control 
returns to step 103 to wait for the next pair of charac- 
ters. If the characters are in the primary language, the 
process proceeds to step 106 where a test is made to 
determine if the caption mode is active. If it is not active 
then the characters are text mode data that can be ig- 
nored and control is returned to step 103 to wait for the 
next two characters. However, the return to step 103 is 
made via step 107 where a test is made to determine if 
the characters received are the control characters that 
switch the character stream into caption mode. If this is 
true, then at step 108 the caption mode is set active. If 
the caption mode is active at step 106, step 109 then tests 
the received characters to determine if they are the 
control characters that switch the character stream into 
text mode, i.e., to set caption mode not active. If so, 
control again returns to step 103 after setting the cap- 
tion mode not active at step 110, Control will proceed 
to step 111 only when caption mode characters are 
being received. Step 111 tests to determine if the char- 
acters received include the control codes to clear mem- 
ory. If not, then these characters form part of the cur- 
rent paragraph and are added to the active buffer. How- 
ever, before adding the characters to the active buffer, 
step 112 tests to determine if these characters are the 
first characters in this paragraph; and, if they are, at step 
113 the active buffer is initialized with the time of day at 
which the characters are received. At step 114, the 
characters received are added to the active buffer and 
control then returns to step 103 to wait for the next two 
characters. If the test at step 111 indicates that the con- 
trol code to clear memory has been received then the 
contents of the active buffer represent a complete 
sensed paragraph. Before transferring the contents of 
the active buffer, i.e., the sensed paragraph, to the 
higher level task, a test is made at step 115 to determine 
if the active buffer is empty, since it is possible that the 
character stream may contain sequential clear com- 
mands and it is preferable to avoid transfer of empty 
active buffers to the higher level task. If the active 
buffer is not empty, then at step 116 the active buffer 
containing the paragraph just received is transferred to 
the higher level task. 

FIG. 5 is a flow chart for the algorithm or task 119 
that is used to compare the sensed paragraphs to the 
library of stored paragraphs. Task 119 processes the 
data buffers that are filled by and transferred from the 
module or task 100. Task 119 processes the data buffers 
and releases them faster than task 100 can fill and trans- 
fer buffers to avoid build-up of a long data buffer queue. 
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Task 119 starts at step 120. At step 121, the task initial- the operator starts VCR 46 to play the tape of a com- 
izes itself, creates and passes a pool of data buffers to mercial to be "memorized" by computer 15. In the loop 
task 100, and then transfers control to task 100 at step formed by steps 144, 145 and 146, task 139 accepts buff- 
101. At step 122 it monitors the pool of data buffers until ers until the tape is stopped. When the tape is stopped, 
one is transferred from task 100. At step 123, the task 5 the task 139 is allowed to proceed to step 147 where the 
119 fetches the oldest available buffer in the queue. At paragraphs in the buffers are checked for communica- 
step 124, the buffer is examined for communication tion errors (parity checks). If errors are detected, the 
errors (parity checks); and if errors have occurred, the task terminates at step 150 rejecting any library entry 
buffer is returned to the pool at step 125 and control that is not perfect, preferably with a suitable error mes- 
returns to step 122. At step 126, data compression trans- 10 sage for the operator. If there are no errors, at step 151 
formation is performed on the paragraph in the buffer to the task 139 performs the character string compression 
create a corresponding key or compressed character on each of the paragraphs. At step 152, an entry is made 
string. At step 127, the library is searched for a match- in the library for each of the compressed strings, 
ing key and, if a match is found, the commercial ID The library created at step 152 is preferably transmit- 
number is returned from the matching key file in the 15 ted to Program Monitoring Unit 8 via telephone net- 
library. If there is no match, control returns through work 14 at an appropriate time when remote system 2 is 
step 125 to step 122. If a match is found, one additional in communication with central computer 15. 
test must be made before making an entry in the data The data defining the household purchase of goods 
log. Each commercial may include more than one and services may be collected using the technique of 
closed captioning paragraph but it is desirable that the 20 consumer questionnaires. The questionnaires can be of 
system make only one entry in the data log for each play the well-known paper diary type or the electronic diary 
of the commercial. Therefore, at step 129 a test is made type in which the panelist interacts with and completes 
to determine if the match is for a commercial ID that is the questionnaire on the household TV set 10. In such a 
current. If the match is not on a current commercial, at case, the purchase data collected from each household 
step 130 an entry is made in the data log and the current 25 may be transmitted via network 14 but in any event is 
ID is set for the commercial that was just identified. entered into the database on the central site computer 
Then the buffer is released at step 125 and the task 15. It is to be understood that other methods of collect- 
returns to step 122 where it waits for a buffer to be ing the purchase data are contemplated, such as in-store 
ready. The current ID is reset at step 130 after a new or in-home UPC symbol scanners, 
commercial has been identified and cleared at step 131 30 To facilitate the generation of reports, the central site 
whenever a match is not made on a valid paragraph. computer 15 contains several tables in which the col- 

As stated previously, at step 130 after a match is lected data is stored. The information that is retrieved 
found, data is entered into a data log. Preferably, the from the households is stored in a viewing table 200 that 
data that is collected includes an ID number for the contains the household ^identification number 202, the 
commercial, and the time at which it was broadcast. It 35 panel identification number 204 (for the case where 
is to be understood that once started, module 119 runs there are multiple panels such as a test and control 
continuously until cancelled. Module 119 will continu- panel) and the program identification code 206 along 
ally process active buffers filled in module 100 and with the time 208 and the date 210 that the program was 
release empty buffers to the pool (for use by module identified as having been viewed in the home. 
100). Although not shown, it is to be further understood 40 A separate demographic table 212 contains the house- 
that the data log created by module 119 is preferably hold identification number 202, panel identification 
periodically interrogated and cleared. number 204 along with a set of demographic data 214 

One of the functions that the central computer 15 associated with the household, 

performs is the creation and maintenance of the library A program table 216 contains the character strings 

Of stored paragraphs, or data compression keys and 45 218 for various programs along with their program 

commercial ID numbers. In FIG. 1, a VCR 46 is prefer- identification codes 206 and other information associ- 

ably located at or near central computer 15. The pur- ated with the program. 

pose of the VCR 46 is to generate (from video tape) the A purchase table 220 contains the collected purchase 
caption mode paragraphs for the commercials that the data 222 of goods and services associated with each 
PMUs 8 are to recognize. The composite output of the 50 household, as well as the program identification code 
VCR is directed to a demodulator — decoder module 48, 206 associated with the various brand categories, brand 
the output of which is input to the computer 15. An items and services. In addition, other tables may be 
operator enters the caption mode text for a commercial maintained in the central computer database to facilitate 
into the library by playing a taped copy of the commer- the generation of various reports as desired, 
cial on the VCR while running a special program on the 55 One standard report that can be generated by the 
computer 15. This program is called the library input software in the central computer 15 is a program view- 
program, ing report 224. This report specifies how many house- 
The algorithm or task 139 for the library input pro- holds in the panel had their television sets tuned to a 
gram is shown in FIG. 6. Task 139 starts at step 140. At predetermined program on a specific date and time or 
step 141 task 139 initializes itself and starts the low level 60 during a preselected time period. Only the data col- 
task 100 which reads the characters and assembles the lected from the households is needed to automatically 
sensed paragraphs. This task must also maintain a pool produce this report. It is not necessary to have centrally 
of data buffers which are shared with the low level task monitored all possible channels on which the program 
100. At step 142, the operator inputs (via a keyboard of of interest could have been broadcast to be able to iden- 
central computer 15) the commercial ID number that is 65 tify the programs viewed in the panelists house. To 
to be assigned to this commercial as well as any other generate this report a computer operator merely enters 
information relevant to that commercial such as prod- the program identification code (PIC) and the desired 
uct category, manufacturer, agency, etc. At step 143, time period into the report generating software. The 
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software then automatically retrieves all records from 
the viewing table that contain the selected PIC and 
meet the requirement of the specified time period. The 
output would be a tabulation of the households that 
viewed the program and the number of times it was 5 
viewed by each household during the selected time 
period. 

By using the data in the viewing table and purchase 
table the software can also generate a household pur- 
chase report 226 that lists all the households that have 10 
viewed a television program and purchased an associ- 
ated service or product. To generate this report the 
operator runs a program that combines the viewing 
table and the purchase table using the household identi- 
fication number as a key. The program then retrieves all 
records from the combined table that contain both the 
PIC and product or service selected by the operator for 
the time period of interest. The program then processes 
this data to produce a table listing the number of view- 20 
ings of the commercial by each household and the quan- 
tity of associated products or services that were pur- 
chased by the household. Each of the reports described 
above can be generated for each panel for the case 
where multiple panels are being monitored. These sepa- 25 
rate reports permit the researchers to closely monitor 
the resulting purchase behavior of panels exposed to 
different amounts or types of commercials. Further 
reports can also be generated incorporating the house- 
holds' demographic characteristics by combining the 30 
demographic table with one or more of the other tables. 
The manner in which the data is stored and collected 
permits the rapid generation of both standard and non- 
standard reports by querying the database at the central 
site. 35 

The invention is not to be taken as limited to all of the 
details thereof, as modifications and variations thereof 
may be made without departing from the spirit or scope 
of the invention; for example, a system which monitors 
only households that are equipped with a cable con- 40 
verter 6 and a cable television signal; however, it is to be 
understood to be within the scope of the present inven- 
tion to determine the television programs being viewed 
on a television set equipped with an external tuner re- 
ceiving a signal via a conventional antenna. As an alter- 45 
native, the cable converter shown in FIG. 1 can be 
replaced with a VCR used to select channels from a 
cable television feed or a conventional antenna. As a 
further alternative, when the tuner in the television set 
is used to tune to a signal from a cable television feed or 
from a conventional antenna, the PMU 8 can be adapted 
to monitor the prograrriming being viewed in the house- 
hold. By inserting a signal tap in the television set to 
feed the output of the television tuner to the decoder 18 « 
in the PMU 8. 

What is claimed is: 

1. A program monitoring unit for monitoring the 
viewing of television programs by collecting data with 
respect to cooperating television viewers or panelists at 50 
a remote location for later transmission to a central 
computer for processing, the program monitoring unit 
comprising: 

a) comparison table storing means for storing an up- 
datable table of character strings; 65 

b) signal acquisition means for acquiring a television 
signal being viewed by the cooperating television 
viewer; 
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c) decoding means for decoding character strings 
from the closed captioning signal that is embedded 
in the viewed television signal; 

d) matching means for matching decoded character 
strings with character strings found in the table of 
character strings; 

e) memory means for storing the decoded character 
strings that match character strings found in the 
table of character strings; 

f) modem means for periodically establishing tele- 
phone communications between the program mon- 
itoring unit and the central computer via a public 
switched telephone network to i) transfer the 
matched character strings stored in the memory 
means to the central computer and ii) periodically 
update the table of character strings stored in the 
comparison table storing means. 

2. A program monitoring unit in accordance with 
claim 1 wherein the character strings stored by the 
program monitoring unit are stored along with the date 
and time at which they were decoded. 

3. A program monitoring unit in accordance with 
claim 2 wherein each character string and the date and 
time at which it was decoded is transferred to the cen- 
tral computer to allow the central computer to deter- 
mine when the television program was viewed. 

4. A program monitoring unit in accordance with 
claim 1 wherein the television programs identified are 
television commercials. 

5. A system for collecting data with respect to coop- 
erating television viewers or panelists comprising: 

a) a remote unit connected to a television receiver 
such that the remote unit is able to monitor televi- 
sion programs being viewed by the cooperating 
television viewers, the remote unit having 

i) first memory means for electronically storing an 
updatable table of character strings and respec- 
tive associated program identification codes such 
that every character string has a corresponding 
program identification code in the table; 

ii) decoding means for decoding a character string 
from the closed captioning signal that is embed- 
ded in a television program being viewed; 

iii) comparing means for comparing each decoded 
character string to the strings stored in the table 
to determine when a match is found; 

iv) second memory means for storing as a data 
event in an event data log the program identifica- 
tion codes corresponding to table character 
strings found to match the decoded character 
strings; 

b) a central computer; 

c) communication means for periodically establishing 
telephone communications between the remote 
unit and the central computer, transferring the data 
events stored in the second memory means to the 
central computer, and for receiving updates to the 
updatable table of character strings; and 

d) associating means in the central computer for asso- 
ciating the data events transferred from the remote 
unit with the television programs viewed. 

6. A system in accordance with claim 5 wherein the 
data events stored by the remote unit further comprise 
a date and time at which the comparing means matched 
the decoded character string with the table character 
string. 



7. A system in accordance with claim 5 wherein the 
television programs identified are television commer- 
cials. 

8. A method of collecting data on television viewing 
experience of a plurality of television viewing panelists 5 
at remote household locations comprising the steps of: 

a) monitoring a television signal being viewed by the 
panelists for character strings found in the closed 
captioning signal embedded in the television signal; 

b) matching the closed captioning character strings to 10 
character strings stored in an updatable table; 

c) recording a program identification code corre- 
sponding to the signal being viewed whenever a 
match is made in step b); 

d) repeating steps a), b) and c) over a predetermined 15 
time interval; 

e) periodically reporting the program identification 
codes recorded in step to a central computer via a 
telephone network; and 

f) periodically receiving updates to the character 20 
strings stored in the table from the central com- 
puter. 

9. The method of claim 8 wherein the television sig- 
nal being viewed comprises a television commercial. 

10. The method of claim 8 wherein step c) further 25 
comprises recording a time at which the signal was 
viewed. 

11. The method of claim 10 wherein step c) further 
comprises recording the date on which the signal was 
viewed. 30 

12. The method of claim 11 wherein step e) further 
comprises reporting the time and date recorded in step 
c) to the central computer. 

13. A system for collecting data on television viewing 
experience comprising: 35 

a) a central computer; and 

b) a plurality of remote household program monitor- 
ing units, each unit having: 

i) decoding means for decoding a character string 
from the closed captioning signal that is embed- 40 
ded in a television program currently being dis- 
played on a television set in the household, 

ii) code storage means for storing program identifi- 
cation codes, 

45 
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iii) means for associating the decoded character 
string with one of the program identification 
codes; 

iv) data log means for electronically storing the 
program identification code that is associated 
with the decoded character string in step ii), 

v) modem means for: 

1) periodically establishing telephone communi- 
cation between each remote program monitor- 
ing unit and the central computer and 

2) transferring the contents of the data log means 
from each remote unit to the central com- 
puter, and 

3) updating the program identification codes 
stored in the code storage means. 

14. The system of claim 13 wherein each program 
monitoring unit further comprises a real-time clock 
means for identifying and recording in the data log the 
date and time at which a particular television program 
was displayed. 

15. The system of claim 14 wherein the particular 
television program displayed comprises a television 
commercial. 

16. The system of claim 13 wherein the central com- 
puter further comprises 

i) viewing table which contains a household identifi- 
cation number, a time and a date corresponding to 
each program identification code transferred from 
the data log means to the central computer; and 

ii) report generating means for generating a program 
viewing report of how many households had their 
television sets tuned to a predetermined program. 

17. The system of claim 16 wherein the viewing table 
further comprises a panel identification number for 
identifying a panel to which each respective household 
belongs. 

18. The system of claim 16 wherein the central com- 
puter further comprises 

iii) a demographic table comprising a set of demo- 
graphic data for each respective household, and 
further wherein the report generating means uti- 
lizes said demographic data in said program view- 
ing report. 

***** 
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ABSTRACT 



A data transmitting node and a network inter-connection 
node suitable for use in the home network environment. In 
a case of transmitting information data from a data trans- 
mitting node connected with a physical network to a receiv- 
ing node connected with the physical network or another 
physical network, a data transmitting node transmits the 
control message including an IP address information of a 
data transmission destination, a header/channel information 
dependent on the physical network, and an information 
indicating that the information data to be transmitted accord- 
ing to the header/channel information is data in an upper 
layer of an IP layer. The information data is then transmitted 
to the receiving node, where the information data contains 
the header/channel information and data of the upper layer 
without IP packet encapsulation. A network inter-connection 
node operates similarly. 

24 Claims, 82 Drawing Sheets 
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DATA TRANSMITTING NODE AND 
NETWORK INTER-CONNECTION NODE 
SUITABLE FOR HOME NETWORK 
ENVIRONMENT 

This is a continuation-in-part application of our earlier 
commonly assigned application Ser. No. 08/943,927 filed 
Oct. 3, 1997, which is now abandoned. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a network system for 
constructing a home network environment, and more 
particularly, to a data transmitting node and a network 
inter-connection node suitable for use in the home network 
environment. 

2. Description of the Background Art 

In recent years, there is a rapid trend for digitalizing 
electronic instruments as exemplified by the term "multi- 
media", and this trend is already noticeable in the office 
environment. 

More specifically, in terms of hardware, this trend has 
been materialized in forms of introduction of PCs, digitali- 
zation of OA devices and formation of networks among 
them. Also, in terms of software, this trend has been expand- 
ing to cover the basic functions of hosts (which are progres- 
sively light-sized and transferred to PCs), the application 
software such as the word-processing software, the spread- 
sheet software, etc., and the Internet application such as the 
WWW. 

The similar trend can also be seen in the home environ- 
ment. Namely, even in the home environment, this trend for 
digitalization has been steadily progressed in forms of 
digitalization of AV devices (DVD, digital VTR, digital 
video camera, etc.), digitalization of broadcasting, and Inter- 
net access such as OCN. 

Similarly as in a case of the office environment, this trend 
is expected to progress toward the formation of networks in 
future. Namely, it is expected that the technologies of 
various fields such as information processing, communica- 
tion and broadcasting will be unified by the digitalization, 
and inter-mixed with each other by the formation of net- 
works. 

There are many candidates for the network technologies 
in this direction. For example, the Ethernet has overwhelm- 
ing records of the actual use in the office environment and 
is probably the most promising candidate even for the home 
PC network. Also, the ATM is another serious contender 
because of the general consensus among the infra-structure 
constructors (telephone companies, CATV companies, etc.) 
to keep constructing the infra-structures based on this tech- 
nology in view of the advantageous characteristics of the 
ATM such as its fast, real-time, and wide bandwidth prop- 
erties. 

In addition to these candidates, the network technology 
(bus technology) called IEEE 1394 has been attracting much 
attentions recently. This IEEE 1394 has several remarkable 
characteristics such as its fast, real-time (QOS guaranteed), 
and plug-and-play properties, so that there is a high expec- 
tation especially among the AV industries on the IEEE 1394 
as the most promising candidate for a future scheme for 
inter-connecting digital AV devices. This vogue has also 
instigated much interests to the IEEE 1394 from the com- 
puter industries as well. 

In the initial phase, it is expected that the inter-connection 
of the home use digital devices will be realized by these 
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various network technologies in conjunction with the spread 
of-the home use digital devices, depending on preferences 
and demands of the users, and in this way prototype digital 
networks will be gradually built up inside each home. 

5 In the second phase, there will be demands for inter- 
connecting these digital networks together. For example, 
there will be a desire to inter-connect an AV device con- 
nected to the 1394 network of a guest room on the first floor 
with another AV device connected to the 1394 network of a 

1° private room on the second floor in order to realize the 
dubbing or the cooperative operation between these AV 
devices. 

However, in order to meet the expected demands of this 
second phase, the following problems must be addressed 
15 and resolved. 

(1) The 1394 network is not suited for a large scale 
installation. For example, its cable length is limited to 4.5 m, 
so that the wiring across rooms will be difficult. Also, the 
plug-and-play function of the 1394 has the side-effect that 

20 the on-going communication will be instantaneously discon- 
nected whenever someone connects to or disconnects from 
the 1394. When the wiring of the 1394 across rooms is 
attempted, there will be an inconveniency in that an action 
made in one room would affect another room in a form of the 

25 instantaneous disconnection of the on-going communication 
because of its "bus reset". 

(2) The standardization of the specification for "1394 
bridge" as the inter-connection protocol/scheme for the 1394 

3Q is currently in progress at the IEEE which is the standard- 
ization committee for the 1394. However, the standard 
specification is expected to be a very complicated one that 
requires the scalability and incorporates a concept of call set 
up, and it is also expected that a considerable amount of time 

35 will be needed before the standard specification can be 
solidified. 

(3) The home network will not necessarily be limited to 
just the 1394, so that it is preferable to construct the home 
network according to a scheme that can inter-connect vari- 

40 ous types of networks. However, no such a network archi- 
tecture has been proposed so far. 

(4) As a known technique for inter-connecting various 
networks, there is the Internet protocol. However, this 
scheme is difficult to set up, manage and maintain for the 

45 layman, and it also requires the server management, so that 
in its currently available form it is not suitable for an 
inter-connection scheme intended for use in the home net- 
work which is expected to deal with a rather limited number 
of terminals. 

50 On the other hand, in recent years, rapid progresses made 
in the communication technology such as Internet are 
attracting much attentions from various fields, and issues 
such as introduction of LAN or connection of that to WAN 
or Internet are much discussed mainly among companies 

55 and universities. 

These technological innovations are highly likely to 
change the network environment surrounding our homes. 
Namely, with the spread of various digital devices such as 
PC, DVD, digital set-top box and so on in our homes, 

60 demands for inter-connecting them through a digital net- 
work inevitably arises. Currently, IEEE 1394 bus is attract- 
ing much attentions from various fields, especially among 
AV vendors, as a prime candidate for such a digital network 
for home use. 

65 This IEEE 1394 bus can be used as a high speed digital 
network of 100, 200 or 400 Mbps, and has several remark- 
able characteristics including plug-and-play properties, syn- 
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chronous transfer function using isochronous channel, etc., 
as already mentioned above. 

Meanwhile, rapid technological innovations are also 
made in the so called access network for homes. Namely, 
notable progresses have been made in high speed network 5 
technologies such as CATV, ADSL (Asymmetric Digital 
Subscriber Line) and FTTH (Fiber-To-The-Home) as well as 
network services such as Internet, and so on. In particular, 
the Internet technology has promoted many remarkable 
techniques including its fast implementation, guarantee of 10 
QOS (Quality Of Service) using network layer level signal- 
ing protocol such as RSVP (Resource Reservation Protocol), 
multicast, and so on. 

In near future where these techniques are realized on 
Internet, transfer of some information that require high 15 
speed and realtime characteristics such as video transfer to 
homes may very well be carried out through Internet. This 
is because Internet can store virtually infinite amount of 
information so that it is only natural for Internet users to 
come to expect acquisition through Internet of the above 20 
noted information which has conventionally been acquired 
from terrestrial or satellite broadcasting and the like. 

However, when exchanges of information through Inter- 
net are attempted by connecting home digital devices 25 
through the access network, the following problems will be 
encountered. 

(1) Currently, a scheme for distributing Internet data over 
IEEE 1394, i.e., IP-over-1394, is discussed by various 
groups, but these discussions still remain at a level of the so 30 
called address resolution scheme. On the other hand, there is 

a proposition of a signaling protocol such as RSVP for 
carrying out data exchanges with guaranteed communica- 
tion quality on Internet. However, a scheme for operating 
such a network layer signaling protocol on IEEE 1394 has 35 
not been standardized so that mapping to a transfer scheme 
that does not guarantee communication quality is the only 
available option for IEEE 1394. 

Consequently, even when the above noted signaling pro- 
tocol is executed, data will be transferred over IEEE 1394 on 40 
the best effort basis (more specifically, through asynchro- 
nous channel) so that the end-to-end communication quality 
cannot be guaranteed. 

(2) In the case of transmission and reception of IP 
multicast on IEEE 1394 bus, the use of isochronous channel 45 
or asynchronous stream of IEEE 1394 can be considered in 
order to minimize traffic on IEEE 1394 bus. However, when 
two or more devices tries to subscribe for the same IP 
multicast at the same time, there is a possibility for these two 

or more devices to reserve different channels separately so 50 
that the efficient utilization of communication resource 
cannot be realized. 

Moreover, there is no mechanism for enabling synchro- 
nized recognition of correspondence between reserved chan- 
nel and IP multicast address by a transmitting side and a 55 
receiving side. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to provide 
a data transmitting node and a network inter-connection 
node which are capable of resolving the above noted prob- 
lems and which are therefore suitable for use in the home 
network environment. 

It is another object of the present invention to provide a 65 
communication device capable of realizing communication 
that guarantees communication quality in an inter-connected 
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network environment even on IEEE 1394, by specifying a 
scheme for applying RSVP to IEEE 1394 bus. 

It is another object of the present invention to provide a 
communication device capable of carrying out IP multicast 
by utilizing communication resource efficiently, and 
enabling recognition of correspondence between reserved 
channel and IP multicast address by a transmitting side and 
a receiving side in synchronization, in a network of broad- 
cast type such as IEEE 1394. 

According to one aspect of the present invention, there is 
provided a data transmitting node connected with a physical 
network, comprising: a first transmission unit for transmit- 
ting a control message in a case of transmitting information 
data to a receiving node through connected with the physical 
network or another physical network, the control message 
including an IP address information of a data transmission 
destination, a header/channel information dependent on the 
physical network, and an information indicating that the 
information data to be transmitted according to the header/ 
channel information is data in an upper layer of an IP layer; 
and a second transmission unit for transmitting the infor- 
mation data to the receiving node, the information data 
containing the header/channel information and data of the 
upper layer without IP packet encapsulation. 

In this aspect of the present invention, it becomes possible 
to explicitly notify a network connection device on a com- 
munication path that the information data that pass through 
a communication path established by the control message 
are not IP packets so that they should be forwarded by a 
datalink layer processing alone without forwarding them to 
the so called IP processing unit for carrying out the routing 
processing of IP packets. 

Namely, by notifying a header/channel information 
according to which the information data is to be transmitted 
later and an IP address of the receiving node to the network 
connection device, it becomes possible to notify that a 
transfer destination of the subsequently transmitted infor- 
mation data which has this header/channel information 
(datalink layer identifier) is the IP address of the receiving 
node, so that the network connection device on the commu- 
nication path can establish the communication path (datalink 
layer communication path) up to the receiving node at the 
datalink layer level. 

In addition, by using the IP address, it becomes possible 
to realize an address system which can be commonly used 
even under an environment in which a plurality of types of 
physical networks are inter-connected, so that it becomes 
possible to carry out the data transmission and the control 
message transmission with respect to nodes belonging to 
physical networks of different transmission schemes. 

Moreover, it is possible to explicitly notify the network 
connection device that the information data that pass 
through the communication path are not IP packets but the 
packets in the upper layer than the IP layer, so that it can be 
expected that the network connection device will transfer the 
information data on the communication path to the receiving 
node without applying the so called IP routing processing, 
and therefore it becomes possible to realize the transmission 
of the so called raw data such as MPEG video and speech 
data. 

Also, in this aspect of the present invention, the control 
message may command to a network inter-connection node 
for connecting said physical network and a next physical 
network a registration of a correspondence between the 
header/channel information dependent on said physical net- 
work and a header/channel information dependent on the 
next physical network. 
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This defines the operation of the control message in this 
aspect of the present invention. 

Also, in this aspect of the present invention, the data 
transmitting node may further comprises: a reception unit 
for receiving digital video and/or digital audio data; wherein 5 
the second transmission unit transmits the digital video 
and/or digital audio data received by the reception unit as the 
information data, by formatting the digital video and/or 
digital audio data into a transmission format for said physi- 
cal network. 10 

In this aspect of the present invention, in a case of 
receiving the raw or MPEG coded video/speech data and 
forwarding the received data to a specific receiving node, as 
in a case of a set-top box for the digital satellite broadcast, 
the digital CATV, or the digital terrestrial broadcast, it 15 
becomes possible to realize this data forwarding by format- 
ting the received data into a format of a physical network. 

According to another aspect of the present invention, 
there is provided a network inter-connection node for trans- 2Q 
mitting information data received from one physical net- 
work to another physical network, comprising: a reception 
unit for receiving a first control message from said one 
physical network, the first control message containing an IP 
address information of a data transmission destination, a first 25 
header/channel information dependent on said one physical 
network, and an information indicating that an information 
data to be transmitted according to the first header/channel 
information is data in an upper layer of a protocol layer 
corresponding to the IP address information; a first trans- 3Q 
mission unit for transmitting a second control message to 
said another physical network when the reception unit 
receives the first control message, the second control mes- 
sage containing the IP address information, a second header/ 
channel information dependent on said another physical 35 
network which is obtained from the IP address information, 
and the information indicating that the information data to 
be transmitted according to the second header/channel infor- 
mation is data in the upper layer; a memory unit for storing 
a correspondence between the first header/channel informa- 4Q 
tion and the second header/channel information; and a 
second transmission unit for obtaining the second header/ 
channel information corresponding to the first header/ 
channel information according to the correspondence stored 
in the memory unit when the information data containing the 45 
first header/channel information is received from said one 
physical network, attaching the second header/channel 
information to the information data, and transmitting the 
information data to said another physical network, the 
information data containing data of the upper layer without 5Q 
IP packet encapsulation. 

In this aspect of the present invention, the information 
data containing the first header/channel information are the 
packets in the upper layer than the IP layer. Consequently, 
each network connection device on the communication path 55 
can recognize that the information data that pass through a 
communication path established by the control message are 
not IP packets so that there should be a setting by which they 
can be forwarded by a datalink layer processing alone 
without forwarding them to the so called IP processing unit 60 
for carrying out the routing processing of IP packets, and 
make this setting to the second transmission unit. As a result, 
it becomes possible to realize a transfer of arbitrary data 
such as MPEG video and speech data in the IP network 
environment. 65 

Also, in this aspect of the present invention, the first 
control message may command a registration of a corre- 
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spondence between the first header/channel information and 
the second header/channel information, and the second 
control message may command to a receiving node or a 
network inter-connection node for connecting said another 
physical network and a third physical network a registration 
of a correspondence between the second header/channel 
information and a header/channel information dependent on 
said third physical network. 

This defines the operations of the first and second control 
messages in this aspect of the present invention. 

According to another aspect of the present invention, 
there is provided a data transmitting node connected with a 
physical network, comprising: a first transmission unit for 
transmitting a control message in a case of transmitting 
information data to a receiving node connected with the 
physical network or another physical network, the control 
message including an IP address information of a data 
transmission destination, a header/channel information 
dependent on the physical network, and an information 
indicating a required communication resource; and a second 
transmission unit for transmitting the information data con- 
taining the header/channel information for which the 
required communication resource is reserved, to the receiv- 
ing node. 

In this aspect of the present invention, it becomes possible 
to explicitly notify a network connection device on a com- 
munication path that the information data that pass through 
a communication path established by the control message 
are requiring this much of the communication resource 
amounts so that this communication resource amounts 
should be reserved in a case of acquiring the communication 
resources (connections, channels, etc.) of the datalink that 
constitutes this communication path. 

In addition, the IP address is used as an address system so 
that it can be realized under the inter-connection environ- 
ment of arbitrary combination of mutually different datalink 
layers and therefore it becomes possible to establish the 
communication path while reserving the communication 
resources under an arbitrary inter-connected network envi- 
ronment. 

Also, in this aspect of the present invention, the control 
message may command to a network inter-connection node 
for connecting said physical network and a next physical 
network a registration of a correspondence between the 
header/channel information dependent on said physical net- 
work and a header/channel information dependent on the 
next physical network for which the required communica- 
tion resource is reserved. 

This defines the operation of the control message in this 
aspect of the present invention. 

Also, in this aspect of the present invention, the data 
transmitting node may further comprises: a reception unit 
for receiving digital video and/or digital audio data; wherein 
the second transmission unit transmits the digital video 
and/or digital audio data received by the reception unit as the 
information data, by formatting the digital video and/or 
digital audio data into a transmission format for said physi- 
cal network. 

In this aspect of the present invention, in a case of 
receiving the raw or MPEG coded video/speech data and 
forwarding the received data to a specific receiving node, as 
in a case of a set-top box for the digital satellite broadcast, 
the digital CATV, or the digital terrestrial broadcast, it 
becomes possible to realize this data forwarding by format- 
ting the received data into a format of a physical network. 

According to another aspect of the present invention, 
there is provided a network inter-connection node for trans- 
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mitting information data received from one physical net- 
work to another physical network, comprising: a reception 
unit for receiving a first control message from said one 
physical network, the first control message containing an IP 
address information of a data transmission destination, a first 5 
header/channel information dependent on said one physical 
network, and an information indicating a required commu- 
nication resource; a first transmission unit for transmitting a 
second control message to said another physical network 
when the reception unit receives the first control message, 10 
the second control message containing a second header/ 
channel information dependent on said another physical 
network which is obtained from the IP address information, 
and the information indicating the required communication 
resource; an establishing unit for establishing a communi- 15 
cation path with respect to a receiving node or a next 
network inter-connection node for connecting said another 
physical network and a third physical network, the commu- 
nication path having the second header/channel information 
with the required communication resource; a memory unit 20 
for storing a correspondence between the first header/ 
channel information and the second header/channel infor- 
mation; and a second transmission unit for obtaining the 
second header/channel information corresponding to the 
first header/channel information according to the correspon- 25 
dence stored in the memory unit when the information data 
containing the first header/channel information is received 
from said one physical network, attaching the second 
header/channel information to the information data, and 
transmitting the information data to said another physical 30 
network. 

In this aspect of the present invention, each network 
connection device on the communication path can recognize 
that the information data that pass through a communication 
path established by the control message are requiring this 35 
much of the communication resource amounts so that this 
communication resource amounts should be reserved in a 
case of acquiring the communication resources 
(connections, channels, etc.) of the datalink that constitutes 
this communication path, establish the datalink layer con- 40 
nection having this communication resource amounts by the 
establishing unit, and make a corresponding setting to the 
second transmission unit. 

In addition, the IP address is used as an address system so 
that it can be realized under the inter-connection environ- 45 
ment of arbitrary combination of mutually different datalink 
layers and therefore it becomes possible to establish the 
communication path while reserving the communication 
resources under an arbitrary inter-connected network envi- 

50 

ronment. 

Also, in this aspect of the present invention, the first 
control message may command a registration of a corre- 
spondence between the first header/channel information and 
the second header/channel information, and the second 55 
control message may command to the receiving node or the 
next network inter-connection node a registration of a cor- 
respondence between the second header/channel informa- 
tion and a header/channel information dependent on said 
third physical network. 6Q 

This defines the operations of the first and second control 
messages in this aspect of the present invention. 

According to another aspect of the present invention, 
there is provided a data transmitting node connected with a 
physical network, comprising: a first transmission unit for 65 
transmitting a control message in a case of transmitting 
information data to a receiving node connected with the 
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physical network or another physical network, the control 
message including an IP address information of a data 
transmission destination, a header/channel information 
dependent on the physical network, and an information on a 
format of the information data to be transmitted according to 
the header/channel information; and a second transmission 
unit for transmitting the information data in said format 
which contains the header/channel information, to the 
receiving node. 

In this aspect of the present invention, it becomes possible 
to explicitly notify a network connection device on a com- 
munication path that the information data that pass through 
a communication path established by the control message 
will be in this format (such as MPEG, JPEG, etc.) so that 
they should be forwarded by a datalink layer processing 
alone without forwarding them to the so called IP processing 
unit for carrying out the routing processing of IP packets, 
and a transfer according to the format transfer scheme 
depending on the datalink layer of a transfer target physical 
network should be made. 

For example, in a case of MPEG, it becomes possible to 
urge the setting by which the MPEG data can be transferred 
in a format depending on the datalink layer, such as "MPEG- 
over-ATM" defined by the ATM forum in while being 
transferred through the ATM network, and "MPEG-over- 
1394" defined by the IEC 61883 while being transferred 
through the IEEE 1394 bus. 

Also, in this aspect of the present invention, the control 
message may command to a network inter-connection node 
for connecting said physical network and a next physical 
network a registration of a correspondence between the 
header/channel information dependent on said physical net- 
work and the header/channel information dependent on the 
next physical network. 

This defines the operation of the control message in this 
aspect of the present invention. 

Also, in this aspect of the present invention, the data 
transmitting node may further comprises: a reception unit 
for receiving digital video and/or digital audio data; wherein 
the second transmission unit transmits the digital video 
and/or digital audio data received by the reception unit as the 
information data, by formatting the digital video and/or 
digital audio data into said format. 

In this aspect of the present invention, in a case of 
receiving the raw or MPEG coded video/speech data and 
forwarding the received data to a specific receiving node, as 
in a case of a set-top box for the digital satellite broadcast, 
the digital CATV, or the digital terrestrial broadcast, it 
becomes possible to realize this data forwarding by format- 
ting the received data into a format of a physical network. 

According to another aspect of the present invention, 
there is provided a network inter-connection node for trans- 
mitting information data received from one physical net- 
work to another physical network, comprising: a reception 
unit for receiving a first control message from said one 
physical network, the first control message containing an 
address information of a data transmission destination, a first 
header/channel information dependent on said one physical 
network, and an information on a format of the information 
data to be transmitted according to the first header/channel 
information; a first transmission unit for transmitting a 
second control message to said another physical network 
when the reception unit receives the first control message, 
the second control message containing the address 
information, a second header/channel information depen- 
dent on said another physical network which is obtained 



US 6,751 

9 

from the address information, and the information on a 
format of the information data to be transmitted according to 
the second header/channel information; a memory unit for 
storing a correspondence between the first header/channel 
information and the second header/channel information; a 5 
conversion unit for converting a transmission format of the 
information data to be transmitted from a transmission 
format in the said one physical network to a transmission 
format in said another physical network; and a second 
transmission unit for obtaining the second header/channel 10 
information corresponding to the first header/channel infor- 
mation according to the correspondence stored in the 
memory unit when the information data containing the first 
header/channel information is received from said one physi- 
cal network, attaching the second header/channel informa- 15 
tion to the information data, and transmitting the informa- 
tion data to said another physical network. 

In this aspect of the present invention, each network 
connection device on the communication path can recognize 
that the information data that pass through a communication 20 
path established by the control message will be in this format 
(such as MPEG, JPEG, etc.) so that they should be for- 
warded by a datalink layer processing alone without for- 
warding them to the so called IP processing unit for carrying 
out the routing processing of IP packets, and there is a need 25 
to carry out the format conversion in order to transfer 
according to the format transfer scheme depending on the 
datalink layer of a transfer target physical network, and 
make necessary settings to the conversion unit and the 
second transmission unit. 30 

Also, in this aspect of the present invention, the first 
control message may command a registration of a corre- 
spondence between the first header/channel information and 
the second header/channel information, and the second 

35 

control message may command to a receiving node or a 
network inter-connection node for connecting said another 
physical network and a third physical network a registration 
of a correspondence between the second header/channel 
information and a header/channel information dependent on 
said third physical network. 40 

This defines the operations of the first and second control 
messages in this aspect of the present invention. 

Also, in this aspect of the present invention, the informa- 
tion data to be transmitted by the second transmission unit 45 
may be MPEG data, and the conversion unit may convert the 
transmission format of the MPEG data from a transmission 
format for the MPEG data in said one physical network to 
a transmission format for the MPEG data in said another 
physical network. 50 

In this aspect of the present invention, by this format 
conversion by the conversion unit, it becomes possible to 
transfer the MPEG data in a format depending on the 
datalink layer, such as "MPEG-over-ATM" defined by the 
ATM forum in while being transferred through the ATM 55 
network, and "MPEG-over-1394" defined by the IEC 61883 
while being transferred through the IEEE 1394 bus. 

According to another aspect of the present invention, 
there is provided a data transmitting node connected with an 
IEEE 1394 bus, comprising: a first transmission unit for 60 
transmitting a control message in a case of transmitting 
information data to a receiving node connected with another 
physical network, the control message including an address 
information of a data transmission destination, and an iso- 
chronous channel number or a register offset indicating an 65 
isochronous channel of said IEEE 1394 bus; and a second 
transmission unit for transmitting the information data in 
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forms of IEEE 1394 packets containing the isochronous 
channel number or the register offset, onto the isochronous 
channel. 

In this aspect of the present invention, it becomes possible 
to explicitly notify a transfer target of the received data to a 
network connection device on a communication path con- 
nected to the IEEE 1394 bus, in such a manner that the 
information data entering from that isochronous channel 
number at the IEEE 1394 interface to which this control 
message is entered will be data destined to that data trans- 
mission destination address. 

In addition, it also becomes possible to explicitly notify 
that the information data that pass through that isochronous 
channel should be forwarded to a next hop network channel 
by a datalink layer processing alone without forwarding 
them to the so called IP processing unit for carrying out the 
routing processing of IP packets. 

Also, in this aspect of the present invention, the control 
message may command to a network inter-connection node 
for connecting said IEEE 1394 bus and a next physical 
network a registration of a correspondence between the 
isochronous channel number of the register offset and a 
header/channel information dependent on the next physical 
network. 

This defines the operation of the control message in this 
aspect of the present invention. 

Also, in this aspect of the present invention, the data 
transmitting node may further comprises: a reception unit 
for receiving digital video and/or digital audio data; wherein 
the second transmission unit transmits the digital video 
and/or digital audio data received by the reception unit as the 
information data, by formatting the digital video and/or 
digital audio data into an IEEE 1394 transmission format. 

In this aspect of the present invention, in a case of 
receiving the raw or MPEG coded video/speech data and 
forwarding the received data to a specific receiving node, as 
in a case of a set-top box for the digital satellite broadcast, 
the digital CATV, or the digital terrestrial broadcast, it 
becomes possible to realize this data forwarding by format- 
ting the received data into a format of a physical network. 

According to another aspect of the present invention, 
there is provided a network inter-connection node for con- 
necting at least two physical networks including an IEEE 
1394 bus and transmitting an information data received from 
one physical network to another physical network, compris- 
ing: a reception unit for receiving a first control message 
from said one physical network, the first control message 
containing an address information of a data transmission 
destination, and a first header/channel information depen- 
dent on said one physical network; a first transmission unit 
for transmitting a second control message to said another 
physical network when the reception unit receives the first 
control message, the second control message containing the 
address information and a second header/channel informa- 
tion dependent on said another physical network which is 
obtained from the address information; a memory unit for 
storing a correspondence between the first header/channel 
information and the second header/channel information, at 
least one of the first header/channel information and the 
second header/channel information including an isochro- 
nous channel number or a register offset indicating an 
isochronous channel of the IEEE 1394 bus; and a second 
transmission unit for obtaining the second header/channel 
information corresponding to the first header/channel infor- 
mation according to the correspondence stored in the 
memory unit when the information data containing the first 
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header/channel information is received from said one physi- 
cal network, attaching the second header/channel informa- 
tion to the information data, and transmitting the informa- 
tion data to said another physical network. 

In this aspect of the present invention, it becomes possible 5 
to carry out the transmission of arbitrary data with respect to 
the receiving node belonging to arbitrary distanced network 
(a physical network to which the transmitting node does not 
belongs), under the environment in which the 1394 buses or 
the 1394 bus and arbitrary physical network are inter- 1° 
connected. 

Namely, in the inter-connected networks in which the 
1394 buses or the 1394 bus and arbitrary physical network 
are inter-connected, it is possible to ascertain the destination 
node ID or channel number and the destination address of 15 
the destination node (which can be the network layer address 
such as IP address or the datalink layer address such as 1394 
address or MAC address) which are the header information 
of the first physical network to which the data will be 
transferred later, from the neighboring node on the side of 20 
the IEEE 1394 bus which is the first physical network. Then, 
from this information, it is possible to notify a correspon- 
dence between the header/channel information to be used at 
the second physical network (virtual connection identifier, or 
destination node ID or channel number, or MAC address, 25 
etc., in the second physical network) and the destination 
address (the address information), to the neighboring node 
on the second physical network side (or conversely, the 
information from the second physical network side is noti- 
fied to the first physical network side). 

In addition, by referring to the header/channel informa- 
tion (channel number, destination node ID, virtual connec- 
tion identifier, MAC address, etc.) of one physical network 
alone, it becomes possible to transfer the data by attaching 
(or converting) the header/channel information (channel 
number, destination node ID, virtual connection identifier, 
MAC address, etc.) of another physical network, so that the 
considerably fast processing becomes possible even 
between the 1394 bus and the other arbitrary physical 
network. 

Moreover, at least one of the first header/channel infor- 
mation and the second header/channel information includes 
an isochronous channel number or a register offset indicat- 
ing an isochronous channel of the IEEE 1394 bus, so that it 45 
becomes possible for the relay device to directly convert the 
isochronous channel number of the IEEE 1394 bus to the 
header/channel information (virtual connection identifier, 
isochronous channel number, MAC address, etc.) of the 
(another) second physical network (or vice versa). 5Q 
Consequently, especially in a case where the end-to-end data 
transfer by the datalink layer switching is desired as in a case 
of the transfer of data that requires the communication 
quality, it becomes possible to realize this data transfer by 
using the isochronous channel of the IEEE 1394 bus and 55 
using the channel number in a similar manner as the virtual 
connection identifier (such as VPI/VQ of the ATM). 

Also, in this aspect of the present invention, said another 
physical network may be an Ethernet or a token ring or a 
FDDI, and the second header/channel information may 60 
indicate a MAC address. 

Also, in this aspect of the present invention, said one 
physical network may be an Ethernet or a token ring or a 
FDDI, and the first header/channel information may indicate 
a MAC address. 65 

In these cases, it becomes possible to recognize the header 
value and its attribute and communication quality on the 
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1394 bus side by providing the correspondence table and the 
conversion table based on the MAC address value, or 
conversely, to recognize the header information value 
(header/channel information depending on the second physi- 
cal network) on the second physical network (another physi- 
cal network) side and its attribute and communication qual- 
ity by providing the table based on the header information 
value of the 1394 bus. Consequently, it becomes possible to 
carry out the data forwarding to the facing network side by 
the datalink layer processing alone, and the fast forwarding 
processing becomes possible. For this reason, it becomes 
possible to use the various frame schemes using MAC 
address as the transmission scheme of the second physical 
network. 

Also, in this aspect of the present invention, said another 
physical network may be an ATM network, and the second 
header/channel information may indicate a VPI/VCI. 

Also, in this aspect of the present invention, said one 
physical network may be an ATM network, and the first 
header/channel information may indicate a VPI/VCI. 

In these cases, it becomes possible to recognize the header 
value and its attribute and communication quality on the 
1394 bus side by providing the correspondence table and the 
conversion table based on the VPI/VCI value, or conversely, 
to recognize a value of the VPI/VCI value (header/channel 
information depending on the second physical network) and 
its attribute and communication quality by providing the 
table based on the header information value of the 1394 bus. 
Consequently, it becomes possible to carry out the data 
forwarding to the facing network side by the datalink layer 
processing alone, and the fast forwarding processing 
becomes possible. For this reason, it becomes possible to use 
the ATM as the transmission scheme of the second physical 
network (another physical network). 

According to another aspect of the present invention, 
there is provided a data transmitting node connected with a 
network, comprising: a first transmission unit for transmit- 
ting a control message in a case of transmitting information 
data to a receiving node connected with another network, the 
control message including a first MAC address information 
of a data transmission destination, and a second MAC 
address information to be attached to the information data; 
and a second transmission unit for transmitting the infor- 
mation data containing the second MAC address 
information, to the receiving node. 

In this aspect of the present invention, it becomes possible 
to explicitly notify a transfer target of the received data to a 
network connection device on a communication path, in 
such a manner that the information data entering with that 
second MAC address at the physical network interface to 
which this control message is entered will be data destined 
to that data transmission destination first MAC address. 

In addition, it also becomes possible to explicitly notify 
that, for the information data entered with that second MAC 
address, the similar control message exchange is to be 
carried out at the subsequent hops and the packet/frame 
routing should be carried out by referring to the MAC 
address alone. 

Also, in this aspect of the present invention, the control 
message may command to a network inter-connection node 
for connecting said network and a next network a registra- 
tion of a correspondence between the second MAC address 
information and a header/channel information dependent on 
the next network. 
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This defines the operation of the control message in this 
aspect of the present invention. 

Also, in this aspect of the present invention, the data 
transmitting node may further comprises: a reception unit 
for receiving digital video and/or digital audio data; wherein 5 
the second transmission unit transmits the digital video 
and/or digital audio data received by the reception unit as the 
information data, by formatting the digital video and/or 
digital audio data into a transmission format for said net- 
work. 10 

In this aspect of the present invention, in a case of 
receiving the raw or MPEG coded video/speech data and 
forwarding the received data to a specific receiving node, as 
in a case of a set-top box for the digital satellite broadcast, 
the digital CATV, or the digital terrestrial broadcast, it 15 
becomes possible to realize this data forwarding by format- 
ting the received data into a format of a physical network. 

According to another aspect of the present invention, 
there is provided a network inter-connection node for trans- 2Q 
mitting information data received from one network to 
another network, comprising: a reception unit for receiving 
a first control message from said one network, the first 
control message containing a first MAC address information 
of a data transmission destination, and a second MAC „ 

. . 25 

address information; a first transmission unit for transmitting 
a second control message to said another network when the 
reception unit receives the first control message, the second 
control message containing the first MAC address 
information, and a third MAC address information which is 3Q 
obtained from the first MAC address information; a memory 
unit for storing a correspondence between the second MAC 
address information and the third MAC address information; 
and a second transmission unit for obtaining the third MAC 
address information corresponding to the second MAC ^ 
address information according to the correspondence stored 
in the memory unit when the information data containing the 
second MAC address information is received from said one 
network, attaching the third MAC address information to the 
information data, and transmitting the information data to 4Q 
said another network. 

In this aspect of the present invention, in the bridge 
network in which two or more physical networks are inter- 
connected, it is possible to ascertain the header information 
(the destination MAC address in the first physical network) 45 
of the first physical network (one physical network) to which 
the data will be transferred later and the destination address 
of its destination node (the MAC address information: the 
final destination MAC address), from the neighboring node 
of the previous hop. Then, from this information, it is 50 
possible to notify a correspondence between the header 
information (the destination MAC address in the second 
physical network) to be used at the second physical network 
(another physical network) and the destination address (the 
MAC address information: the final destination MAC 55 
address), to the neighboring node. 

In addition, by referring to the header information (the 
destination MAC address in the first physical network) of 
said physical network alone, it becomes possible to transfer 
the data by attaching (or converting) the header information 
(MAC address) of the second physical network, so that the 
considerably fast processing becomes possible even 
between different types of networks. Here, the MAC address 
may be used as a logical value, that is, as the virtual 
connection identifier. 65 

According to another aspect of the present invention, 
there is provided a network inter-connection node for con- 
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necting at least two physical networks, comprising: a request 
receiving unit for receiving from a first physical network an 
address resolution request for resolving a datalink layer 
address from a network layer address; a forwarding unit for 
forwarding the address resolution request with respect to a 
connected physical network other than the first physical 
network; a response receiving unit for receiving from a 
second physical network a first address resolution response 
corresponding to the address resolution request forwarded 
by the forwarding unit; a registration unit for registering a 
correspondence between the network layer address and the 
second physical network into a routing table, by referring to 
a network layer source address or a network address con- 
tained in the first address resolution response; and a response 
transmitting unit for transmitting to the first physical net- 
work a second address resolution response corresponding to 
the address resolution request received by the request receiv- 
ing unit, by inserting a datalink layer address of said network 
inter-connection node device as a resolved address. 

In this aspect of the present invention, when the first 
physical network and the second physical network are the 
networks using different address systems (such as the Eth- 
ernet and the IEEE 1394, for example), or when they are 
networks using the same address system which are however 
connected without using a bridge connection, it becomes 
possible to carry out a delivery of a packet to a desired node 
by specifying an address of this network inter-connection 
node as a packet destination with respect to a node which 
transmitted the address resolution request and carrying out 
the routing of a packet received at this network inter- 
connection node. 

In addition, in this aspect of the present invention, the 
network layer address learning function is provided, so that 
it is possible to deal with a case where an entry or with- 
drawal of a node with respect to a network is to be made 
dynamically. 

Also, in this aspect of the present invention, the network 
inter-connection node device may further comprises a trans- 
fer unit for transferring a received packet to a physical 
network registered in the routing table, according to a 
network layer destination address of the received packet. 

Also, in this aspect of the present invention, the response 
transmitting unit may activate the forwarding unit when a 
network layer address contained in the address resolution 
request received from the first physical network is not a 
network layer address of said network inter-connection node 
device and not registered in the routing table, and transmit 
the second address resolution response otherwise. 

Also, in this aspect of the present invention, the first 
physical network and the second physical network may be 
operated by different datalink protocols. 

According to another aspect of the present invention there 
is provided unication device connected with a network of 
broadcast type (such as IEEE 1394), comprising: a reception 
unit for receiving a first message which is a control message 
for bandwidth reservation with respect to a network layer 
data flow, including a first identifier for identifying the 
network layer data flow, from a second communication 
device connected with the network; an establishing unit for 
establishing a broadcast type channel (such as isochronous 
channel or asynchronous stream of IEEE 1394) on the 
network according to the first message received by the 
reception unit; and a transmission unit for transmitting a 
second message which contains at least a correspondence 
between a second identifier of the broadcast type channel 
established by the establishing unit and the first identifier of 
the network layer data flow, to the second communication 
device. 
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In this aspect of the present invention, in a control 
protocol for bandwidth reservation with respect to a network 
layer data flow such as RSVP in Internet, a node which 
received a control message (first message, which is PATH 
message or RESV message in the case of RSVP) reserves a 5 
broadcast type channel (such as isochronous channel or 
asynchronous stream of IEEE 1394) on that network, so that 
it is possible to reserve the required communication resource 
in a form of the broadcast type channel, and it becomes 
possible to realize communication with end-to-end commu- 10 
nication resource reserved as should be realized by the 
network layer level signaling protocol. 

In addition, the second message can also be used for 
realizing transfer to a next hop network without requiring a 
routing processing in the network layer, by referring only to 15 
a datalink transfer at a network boundary, that is an identifier 
of a datalink layer (such as an identifier of the broadcast type 
channel), and indirectly recognizing the network layer flow 
transferred by a channel having that identifier. The second 
message can also be used by a downstream node to prepare 20 
for receiving of the network layer flow from that channel, or 
by an upstream node to prepare for transmission of the 
network layer flow to that channel. 

Also, in this aspect of the present invention, the first 
message may be a message for requesting bandwidth 25 
reservation, which is transmitted from the second commu- 
nication device connected to a downstream direction of the 
network layer data flow. 

In this case, an upstream side node of the network layer 
flow can realize the bandwidth reservation in a form of 30 
bandwidth resource reservation for the broadcast type net- 
work. Namely, an upstream side node of the network layer 
flow can realize this bandwidth reservation in response to a 
bandwidth reservation request from a downstream direction, 
as in a case of receiving RESV of RSVP as the first message. 35 

Also, in this aspect of the present invention, the first 
message may be a message for notifying bandwidth to be 
used, which is transmitted from the second communication 
device connected to an upstream direction of the network 

40 

layer data flow. 

In this case, a downstream side node of the network layer 
flow can realize the bandwidth reservation in a form of 
bandwidth resource reservation for the broadcast type net- 
work. Namely, a downstream side node of the network layer 45 
flow can realize this bandwidth reservation in response to a 
control message for bandwidth reservation from an upstream 
direction, as in a case of receiving PATH of RSVP as the first 
message. 

Also, in this aspect of the present invention, the commu- 50 
nication device may further comprises: a second transmis- 
sion unit for transmitting a message for requesting band- 
width reservation to the second communication device 
which is connected to an upstream direction of the network 
layer data flow. 55 

In this case, it becomes possible to transmit a message for 
bandwidth reservation in the network layer such as RESV 
message of RSVP to the second communication device of 
the upstream side, so that it becomes possible to realize the 
end-to-end bandwidth reservation. 60 

Also, in this aspect of the present invention, the trans- 
mission unit may transmit the second message in a form of 
writing into a register provided at the second communication 
device. 

In this case, it becomes possible to realize a notification 65 
of the correspondence between the identifier of the estab- 
lished broadcast type channel and the identifier of the 
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network layer data flow in a form of writing into register, 
which is a generally known means for transmitting control 
information in a network of broadcast type such as IEEE 
1394. This correspondence is an information regarding the 
datalink layer channel, so that it is appropriate to use a 
register for transmitting datalink layer control information, 
and it becomes unnecessary to provide a mechanism for 
receiving and interpreting this correspondence in the net- 
work layer. 

According to another aspect of the present invention, 
there is provided a communication device connected with a 
network of broadcast type, comprising: a register for regis- 
tering a correspondence between an identifier of a broadcast 
type channel established on the network which is to be used 
in transmitting and receiving a network layer data flow and 
an identifier of the network layer data flow; and a transmis- 
sion and/or reception unit for transmitting and/or receiving 
the network layer data flow through the broadcast type 
channel according to the correspondence registered in the 
register. 

In this aspect of the present invention, it becomes possible 
to notify to another node or obtain from another node a 
correspondence between a broadcast type channel identifier 
of a broadcast type network (such as IEEE 1394) described 
in this register and an information regarding a flow that 
passes through that channel. This correspondence is an 
information regarding the datalink layer channel, so that it is 
appropriate to use a register for transmitting datalink layer 
control information, and it becomes unnecessary to provide 
a mechanism for receiving and interpreting this correspon- 
dence in the network layer. 

By using this register, when a node having this register is 
a transmitting node, it becomes possible for another node of 
the broadcast type network to recognize which flow is going 
to be transferred through the broadcast type channel of the 
broadcast type network described in this register (which 
flow is to be transmitted by the transmitting node), by 
referring to this register. 

Also, when a node having this register is a transmitting 
node, it becomes possible for this transmitting node to 
recognize which flow is going to be transferred through the 
broadcast channel of the broadcast type network described 
in this register (which flow is to be transmitted by the 
transmitting node), as another node of the broadcast type 
network writes the correspondence into this register. 

Also, when a node having this register is a receiving node, 
it becomes possible for this receiving node to recognize 
which flow is going to be transferred through the broadcast 
channel of the broadcast type network described in this 
register (which flow is to be received by the receiving node), 
as another node of the broadcast type network writes the 
correspondence into this register. 

Also, this register may have a field for distinguishing 
transmission and reception. By means of this, it becomes 
possible to clearly indicate whether this register is to be used 
by the transmitting node or the receiving node. 

According to another aspect of the present invention, 
there is provided a communication device connected with a 
network of broadcast type, comprising: a reception unit for 
receiving a subscription request for a network layer multi- 
cast address from a second communication device connected 
with the network; an establishing unit for establishing a 
broadcast type channel on the network in response to the 
subscription request received by the reception unit; a noti- 
fication unit for notifying at least a correspondence between 
an identifier of the broadcast type channel established by the 
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establishing unit and the network layer multicast address, to 
the second communication device; and a transmission unit 
for transmitting data destined to the network layer multicast 
address to the broadcast type channel established by the 
establishing unit. 5 

In this aspect of the present invention, the isochronous 
channel for transmitting the corresponding network layer 
multicast is established by an IGMP router which receives 
the subscription request for that multicast address, so that it 
becomes possible to prevent communication resource within 1° 
the network from being wasted by establishing a plurality of 
channels with respect to the identical multicast address. 

Also, by notifying the correspondence between the iden- 
tifier of the established broadcast type channel and the 
network layer multicast address to the second communica- 15 
tion device, it becomes possible to notify a channel from 
which the multicast data can be received to the second 
communication device (receiving terminal), and in addition 
it becomes possible to accommodate a plurality of receiving 
terminals through a single channel because the broadcast 20 
type channel is used. 

Also, in this aspect of the present invention, the commu- 
nication device may further comprises: a second reception 
unit for receiving from the second communication device a 
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request for reservation of bandwidth required in receiving 
the data destined to the network layer multicast address from 
the second communication device; and a reservation unit for 
reserving bandwidth of the broadcast type channel estab- 
lished by the establishing unit in response to the request 
received by the second reception unit. 

In this case, it becomes possible to realize the transmis- 
sion in a form that guarantees communication quality of the 
multicast. 

According to another aspect of the present invention, 35 
there is provided a communication device, connected with a 
network of broadcast type, for transmitting data destined to 
a network layer multicast address, comprising: a reservation 
unit for reserving bandwidth for a broadcast type channel; a 
first transmission unit for transmitting the data destined to 40 
the network layer multicast address by using a period or 
connection for which the bandwidth of the broadcast type 
channel on the network is not reserved; and a second 
transmission unit for transmitting the data destined to the 
network layer multicast address by switching the period or 45 
connection used in the first transmission unit to a period or 
connection for which the bandwidth of the broadcast type 
channel is reserved, when the bandwidth is reserved for the 
broadcast type channel by the reservation unit. 

In this aspect of the present invention, in a case of 50 
switching the network layer multicast packet transmission 
from a form of not reserving bandwidth to a form of 
reserving bandwidth, it becomes unnecessary to request the 
reservation of both the broadcast type channel and the 
bandwidth to a manager which is managing communication 55 
resource (such as isochronous resource manager in IEEE 
1394) again, as required conventionally. Namely, it is pos- 
sible to realize this switching by simply sending packets for 
the broadcast type channel that is already reserved as 
communication resource into the first transmission unit. The 60 
same also applies to the switching in the reserve direction 
(from a form of reserving bandwidth to a form of not 
reserving bandwidth). 

Also, in this aspect of the present invention, an identifier 
of the broadcast type channel to which the data are outputted 65 
from the second transmission unit when the bandwidth is 
reserved by the reservation unit may be identical to an 



,221 Bl 

18 

identifier of the broadcast type channel to which the data are 
outputted from the first transmission unit when the band- 
width is not reserved. 

In this case, it becomes possible to prevent wasteful use 
of the broadcast type channel. In particular, for the datalink 
in which channel resource is relatively limited such as IEEE 
1394, it becomes possible to share the same channel among 
the network layer multicast packets to be transmitted in a 
form of reserving bandwidth and multicast packets to be 
transmitted in a form of not reserving bandwidth, so that the 
efficient utilization of communication resource can be real- 
ized. 

Other features and advantages of the present invention 
will become apparent from the following description taken 
in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram showing an exemplary overall 
configuration of a communication network according to the 
firs t embodiment of the present invention. 

FIG. 2 is a diagram showing an exemplary correspon- 
dence between IP addresses and datalink layer addresses 
(ATM addresses) on an IP subnet Na side in the communi- 
cation network of FIG. 1. 

FIG. 3 is a diagram showing an exemplary correspon- 
dence between IP addresses and datalink layer addresses 
(ATM addresses) on an IP subnet Nb side in the communi- 
cation network of FIG. 1. 

FIG. 4 is a sequence chart for an operation sequence 
between a guide server and a video terminal in the commu- 
nication network of FIG. 1. 

FIG. 5 is a block diagram showing default VCs in an 
intra-station ATM backbone network in the communication 
network of FIG. 1. 

FIG. 6 is a block diagram showing an exemplary internal 
configuration of a cell switch router in the communication 
network of FIG. 1. 

FIG. 7 is a sequence chart for an address resolution 
sequence between a cell switch router and a video terminal 
in the communication network of FIG. 1. 

FIG. 8 is another sequence chart for an address resolution 
sequence between a cell switch router and a video terminal 
in the communication network of FIG. 1. 

FIG. 9 is a diagram showing one example of a channel 
used for exchanging ARP packets in the communication 
network of FIG. 1. 

FIG. 10 is a block diagram showing an exemplary internal 
configuration of a NIU (Network Interface Unit) in the 
communication network of FIG. 1. 

FIG. 11 is a diagram showing one example of a routing 
table provided in a FANP node in the communication 
network of FIG. 1. 

FIG. 12 is a flow chart for an ARP processing sequence in 
the communication network of FIG. 1. 

FIG. 13 is a diagram showing one example of a format for 
an ARP request packet on a 1394 bus in the communication 
network of FIG. 1. 

FIG. 14 is a block diagram showing an exemplary internal 
configuration of a 1394 gateway in the communication 
network of FIG. 1. 

FIG. 15 is a diagram showing one example of a format for 
an ARP response packet on a 1394 bus in the communication 
network of FIG. 1. 

FIG. 16 is a diagram showing one example of a format for 
an IP packet transmitted on a 1394 bus in the communication 
network of FIG. 1. 



US 6,7: 

19 

FIG. 17 is a sequence chart for a sequence of a video 
transmission from a video server to a video terminal in the 
communication network of FIG. 1. 

FIG. 18 is a further detailed sequence chart for a sequence 
of a video transmission from a video server to a video 
terminal in the communication network of FIG. 1. 

FIG. 19 is a diagram showing one example of a corre- 
spondence table provided in a 1394 switch unit in the 1394 
gateway of FIG. 14. 

FIG. 20 is a diagram showing one example of a format for 
a VCID exchange message used in the communication 
network of FIG. 1. 

FIG. 21 is a diagram showing one example of a default 
data connection (VC) and a dedicated data connection 
between a video server and a video terminal in the commu- 
nication network of FIG. 1. 

FIG. 22 is a sequence chart for an operation sequence of 
FANP message exchanges between a guide server and a cell 
switch router in the communication network of FIG. 1. 

FIG. 23 is a diagram showing one example of a format for 
a flow exchange message used in the operation sequence of 
FIG. 22. 

FIG. 24 is a diagram showing one example of a format for 
a flow exchange message (offer message) used in the opera- 
tion sequence of FIG. 22. 

FIG. 25 is a diagram showing one example of a format for 
a flow exchange message (pending message) used in the 
operation sequence of FIG. 22. 

FIG. 26 is a diagram showing one example of a format for 
a VCID exchange message on a 1394 bus used in the 
operation sequence of FIG. 22. 

FIG. 27 is a diagram showing one example of a format for 
a VCID exchange message (re-direct message) on a 1394 
bus used in the operation sequence of FIG. 22. 

FIG. 28 is a diagram showing one example of a datalink 
connection from a video server to a video terminal in the 
communication network of FIG. 1. 

FIG. 29 is a sequence chart for a datalink connection 
release sequence in the communication network of FIG. 1. 

FIG. 30 is a sequence chart for an operation sequence in 
a case of maintaining and releasing a datalink connection in 
a soft state in the communication network of FIG. 1. 

FIG. 31 is a diagram for explaining a manner of using a 
flow ID in a case of merging information data flows from 
two or more sources into an identical datalink connection in 
the communication network of FIG. 1. 

FIG. 32 is a sequence chart for an operation sequence in 
a case of carrying out a bandwidth reservation control 
between a cell switch router and a video terminal by using 
an extended FANP in the communication network of FIG. 1. 

FIG. 33 is a block diagram showing an exemplary overall 
configuration of a communication network according to the 
second embodiment of the present invention. 

FIG. 34 is a block diagram showing an exemplary internal 
configuration of a half gateway in the communication net- 
work of FIG. 33. 

FIG. 35 is a diagram showing one example of a corre- 
spondence table (for a case of transmitting data received 
from a 1394 side to an Ethernet side) provided in a 1394/ 
Ethernet transfer unit in the half gateway of FIG. 34. 

FIG. 36 is a diagram showing one example of a corre- 
spondence table (for a case of transmitting data received 
from an Ethernet side to a 1394 side) provided in a 1394/ 
Ethernet transfer unit in the half gateway of FIG. 34. 
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FIG. 37 is a sequence chart for an ARP sequence in the 
communication network of FIG. 33. 

FIG. 38 is a sequence chart for an operation sequence up 
to a video transmission in the communication network of 
5 FIG. 33. 

FIG. 39 is a diagram showing one example of a video 
transmission route from a transmitting terminal to a receiv- 
ing terminal in the communication network of FIG. 33. 

10 FIG. 40 is a diagram showing one example of a physical 
shape of a 1394 inter-connection cable, in a case of using an 
Ethernet cable as a cable for connecting two half gateways. 

FIG. 41 is a diagram showing another example of a 
physical shape of a 1394 inter-connection cable, in a case of 

15 connecting two half gateways by radio transmission path. 
FIG. 42 is a block diagram showing an exemplary con- 
figuration of a home network with a transmitting terminal 
having a function for receiving MPEG video from a digital 
satellite broadcast (or digital CATV). 

20 FIG. 43 is a block diagram showing an exemplary internal 
configuration of a transmitting terminal in the home network 
of FIG. 42. 

FIG. 44 is a block diagram showing another exemplary 
internal configuration of a transmitting terminal in the home 
25 network of FIG. 42. 

FIG. 45 is a block diagram showing an exemplary overall 
configuration of a communication network according to the 
third embodiment of the present invention. 
3Q FIG. 46 is a block diagram showing an exemplary internal 
configuration of a FANP node in the communication net- 
work of FIG. 45. 

FIG. 47 is a sequence chart for an ARP sequence in the 
communication network of FIG. 45. 
35 FIG. 48 is a sequence chart for an operation sequence up 
to a video transmission in the communication network of 
FIG. 45. 

FIG. 49 is a diagram showing one example of a video 
transmission route from a transmitting terminal to a receiv- 
40 ing terminal in the communication network of FIG. 45. 

FIG. 50 is a diagram showing still another example of a 
physical shape of a 1394 inter-connection cable, in a case of 
using a relatively short dedicated 1394 cable and a long 
Ethernet cable. 

45 FIG. 51 is a block diagram showing an exemplary overall 
configuration of a communication network according to the 
fourth embodiment of the present invention, in a case of 
connecting two half gateways through an ATM communi- 
cation path. 

50 FIG. 52 is a block diagram showing an exemplary internal 
configuration of a half gateway in the communication net- 
work of FIG. 51. 

FIG. 53 is a block diagram showing another exemplary 

55 overall configuration of a communication network accord- 
ing to the fourth embodiment of the present invention, in a 
case of connecting two half gateways through a FANP -ATM 
switch. 

FIG. 54 is a block diagram showing an exemplary internal 
60 configuration of a FANP- ATM switch in the communication 
network of FIG. 53. 

FIG. 55 is a block diagram showing an exemplary overall 
configuration of a communication network according to the 
fifth embodiment of the present invention. 
65 FIG. 56 is a block diagram showing an exemplary internal 
configuration of a third gateway in the communication 
network of FIG. 55. 
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FIG. 57 is a sequence chart for an operation sequence 
from an ARP up to a video transmission in the communi- 
cation network of FIG. 55. 

FIG. 58 is a block diagram showing an exemplary overall 
configuration of a network system according to the sixth 5 
embodiment of the present invention. 

FIG. 59 is a sequence chart for a processing in the system 
of FIG. 58 in a case of video transfer from a video server to 
a terminal. 

FIG. 60 is a flow chart for the operation by a terminal in 10 
the system of FIG. 58 during the processing of FIG. 59. 

FIG. 61 is a flow chart for the operation by a connection 
device in the system of FIG. 58 during the processing of 
FIG. 59. 

FIG. 62 is a diagram showing an exemplary correspon- 
dence table stored by the connection device in the system of 
FIG. 58. 

FIG. 63 is a diagram showing an exemplary format of a 
PATH message of RSVP that can be used in the system of 20 
FIG. 58. 

FIG. 64 is a diagram showing an exemplary description in 
a PCR register of IEEE 1394 that can be used in the system 
of FIG. 58. 

FIG. 65 is a sequence chart for a processing in the system 25 
of FIG. 58 in a case of video transfer from a video server to 
a terminal by reserving communication resource on IEEE 
1394 from a downstream node of RSVP. 

FIG. 66 is a diagram showing a case of transferring 
different contents by seceding from the already subscribed 30 
IP multicast address and subscribing for a different IP 
multicast address in the system of FIG. 58. 

FIG. 67 is a diagram showing a case of changing contents 
while using the same IP multicast address in the system of 
FIG. 58. 

FIG. 68 is a block diagram showing an exemplary overall 
configuration of a network system according to the seventh 
embodiment of the present invention. 

FIG. 69 is a sequence chart for a processing in a case 40 
where a terminal subscribes for IP multicast in the system of 
FIG. 68. 

FIG. 70 is a flow chart of the operation by an IGMP router 
in the system of FIG. 69 in a case of subscription for IP 
multicast address. 45 

FIG. 71 is a diagram showing an exemplary format of a 
layer-3 flow register used in the system of FIG. 68. 

FIG. 72 is a flow chart for the operation by an IGMP 
router in the system of FIG. 69 in a case of secession from 
IP multicast address. 

FIG. 73 is a sequence chart for a processing of reserving 
bandwidth for asynchronous stream reserved for IP multi- 
cast in the system of FIG. 68. 

FIG. 74 is a sequence chart for a processing of notifying 55 
a correspondence between IP multicast flow and channel 
number by using FANP in the system of FIG. 68. 

FIG. 75 is a diagram showing an exemplary format of a 
FANP OFFER message that can be used in the system of 
FIG. 68. . . oo 

FIG. 76 is a sequence chart for a processing in a case of 
transmitting a plurality of flows by using the same IP 
multicast address in the system of FIG. 68. 

FIG. 77 is a flow chart for the operation of an IGMP router 
in the system of FIG. 68 in a case of transmitting IP multicast 65 
data with amount of bandwidth greater than that reserved in 
advance for isochronous channel. 
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FIG. 78 is a block diagram of an exemplary configuration 
for realizing the operation of FIG. 77 in the system of FIG. 
68. 

FIG. 79 is a sequence chart for a processing in a case of 
reserving bandwidth for asynchronous stream reserved for 
IP multicast and using different channel number for isoch- 
ronous channel with reserved bandwidth in the system of 
FIG. 68. 

FIG. 80 is a sequence chart for a processing in a case of 
transmission from a plurality of senders with respect to the 
same IP multicast address in the system of FIG. 68. 

FIGS. 81A and 81B are diagrams showing exemplary 
configuration of IP multicast data transmitted from terminals 
A and B in the system of FIG. 68 during the processing of 
FIG. 80. 

FIG. 82 is a sequence chart for a processing in a case of 
transmission from a plurality of senders with respect to the 
same IP multicast address and using bandwidth reservation 
in the system of FIG. 68. 

FIG. 83 is a sequence chart for a processing in a case of 
transmission from a plurality of senders with respect to the 
same IP multicast address and using bandwidth reservation 
and different channel numbers for isochronous channel and 
asynchronous stream in the system of FIG. 68. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

First Embodiment 

Referring now to FIG. 1 to FIG. 32, the first embodiment 
of the present invention will be described in detail. 

FIG. 1 shows an exemplary configuration of a commu- 
nication network system according to this first embodiment, 
which is formed by a CATV network and a home network 
connected thereto, for example. 

As shown in FIG. 1, the communication network system 
of this first embodiment comprises a video server 101, a 
program guide delivery server (referred hereafter as a guide 
server) 102, an intra-station ATM backbone network 110, a 
cell switch router (CSR) 103, an access ATM network 111, 
an NIU (network Interface Unit) 104, a first IEEE 1394 bus 
112, a 1394 gateway 105, a second IEEE 1394 bus 113, and 
a video terminal 106. The whole system (or at least a part of 
a group of devices constituting this system) is assumed to be 
subscribed to the Internet. 

The video server 101, the guide server 102, the intra- 
station ATM backbone network 110 and the cell switch 
router 103 are the CATV head-end equipments, and located 
inside the CATV station. They are assumed to be belonging 
to an IP (Internet Protocol) subnet Na. 

The video server 101 receives a control from the guide 
server 102, and delivers a specified video with respect to a 
specified address. Here, the specified address may be given 
by the IP address. 

The guide server 102 delivers the Web-based (i.e., HTTP- 
based) program guide through the Internet. The guide server 
102 also has a function to notify the content, the attributes, 
the delivery destination, etc., of a requested program to the 
video server 101 and control the video server 101. The guide 
server 102 also has a function for authenticating and charg- 
ing users. 

The intra-station ATM backbone network 110 is an ATM 
network constituting the backbone inside the CATV station. 

The cell switch router 103 is a device as disclosed in 
Japanese Patent Application No. 7-58196 (1995), and con- 
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tains an IP processing unit and an ATM switch therein. By 
using the FANP (Flow Attribute Notification Protocol) to be 
described below, the cell switch router 103 is operated by 
carrying out the protocol exchanges between neighboring 
FANP nodes (nodes that can carry out the FANP processing). 5 
More specifically, the datalink layer connection information 
(VPI/VCI of ATM, etc.) with a starting point (ending point) 
at this cell switch router 103 is exchanged between the 
neighboring FANP nodes, and both connections are coupled 
by the ATM switch inside this cell switch router 103 so as 10 
to realize the ATM switching. 

Note that, in the present invention, functions of the FANP 
are upgraded and modified from those disclosed in Japanese 
Patent Application No. 7-58196 (1995), so that the FANP 
used in the present invention will be considered as having a 15 
version number [2] in contrast to the FANP used in Japanese 
Patent Application NO. 7-58196 (1995) which is considered 
as having a version number [1], in a sense that the former is 
the upgraded version of the latter. 

The access ATM network 111 connects the CATV station 20 
with the home. More specifically, it suffices for this part to 
use the ATM as the datalink scheme, and the subscriber line 
form can be any suitable form such as FTTH (Fiber To The 
Home), HFC (Hybrid Fiber Coax), coaxial cable, ADSL 
(Asymmetric Digital Subscriber Line), etc. 25 

The NIU 104, two 1394 buses 112 and 113, the 1394 
gateway 105 and the video terminal 106 are devices or 
networks provided inside the home. 

The NIU 104 has a function to terminate the access ATM 
network 111 and a function to make an inter-connection with 30 
the home network. As described below, this node is also the 
FANP node. 

Two 1394 buses 112 and 113 are home networks formed 
by high speed buses called IEEE 1394. In FIG. 1, the first 
1394 bus 112 is connected only with the NIU 104 and the 3 
1394 gateway 105 while the second 1394 bus 113 is con- 
nected only with the 1394 gateway 105 and the video 
terminal 106, but in practice, these 1394 buses may also be 
connected with various other digital devices such as PC, 

40 

printer, DVD, etc. 

The 1394 gateway 105 is a device having a function to 
connect two (or more) 1394 buses together. Also, the 1394 
gateway 105 in this first embodiment is the FANP node as 
will be described below. 

45 

The video terminal 106 is a terminal having a video 
reception function and an IP processing function. 

Here, it is assumed that the cell switch router 103 and the 
group of devices or networks within the home are belonging 
to one IP subnet. Namely, it is assumed that one (or more) 50 
IP subnet is assigned to each home. In this first embodiment, 
it is assumed that this IP subnet is assigned with the subnet 
address Nb. 

Also, as shown in FIG. 1, it is assumed that the IP address 
of the video server is Na. 1, the IP address of the guide server 55 

102 is Na. 2, the IP address of the intra-station ATM 
backbone network 110 side interface of the cell switch router 

103 is Na. 3, and the IP address of the access ATM network 
111 side interface of the cell switch router 103 is Nb. 4. Also, 

it is assumed that the IP address of the NIU 104 is Nb. 3, the 60 
IP address of the 1394 gateway 105 is Nb. 2, and the IP 
address of the video terminal 106 is Nb. 1. Here, each of the 
NIU 104 and the 1394 gateway 105 can have only one IP 
address even though more than one network interfaces are 
provided therein. 65 

FIG. 2 shows a correspondence between the addresses on 
the IP subnet Na side, that is, the IP addresses within the 
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intra-station ATM backbone network 110, and the datalink 
layer addresses (ATM addresses). Here, it is assumed that 
the ATM address prefix of the intra-station ATM backbone 
network 110 is Aa. 

Similarly, FIG. 3 shows a correspondence of the addresses 
on the IP subnet Nb side. 

Here, it is assumed that the ATM address prefix of the 
access ATM network 111 is Ab, the bus ID of the first 1394 
bus 112 is Bb, and the bus ID of the second 1394 bus 113 
is Ba. 

A terminal connected to each 1394 bus has two 1394 
addresses. One is the address called EUI64 whose value 
remains unchanged by the bus reset, and the other is the node 
ID whose value may be changed by the bus reset. Here, the 
node ID is expressed by an expression format of (Bus ID, 
Physical ID). 

Next, the operation of the entire system of FIG. 1 in a case 
of video transmission will be described with reference to the 
flow chart of FIG. 4. 

First, the video terminal 106 receives the program guide 
transmitted from the guide server 102. 

This program guide is produced by the HTML (HyperText 
Markup Language) and its transmission protocol is the 
HTTP (HyperText Transfer Protocol), for example. Namely, 
the video terminal 106 is in a form of the Web terminal 
(browser), and the program guide itself is transmitted 
through the IP (Internet Protocol). 

Here, the mechanism by which a general IP packet is 
transmitted will be described for each part of the entire 
system. Note that, the general IP packet is an IP packet for 
which the best-effort transmission is to be carried out, which 
is not belonging to a specific flow (that is, a set of a series 
of mutually significant IP packets such as a specific video 
stream) specified by a user or a device. 

As shown in FIG. 5, a VC (Virtual Connection) 501 for IP 
packet transmission is set up in advance between the guide 
server 102 and the cell switch router 103. Also, the similar 
VC 502 is set up in advance between the video server 101 
and the cell switch router 103, and the similar VC 503 is set 
up in advance between the video server 101 and the guide 
server 102. When there is no specific specification (by the 
FANP), these VCs are VCs set up by the default function for 
the purpose of transferring IP packets therethrough. These 
VCs will be referred hereafter as the default VCs. 

The default VC may be a VC which is established by the 
ATM-ARP (ATM-Address Resolution Protocol) inside the 
intra-station ATM backbone network 110. This will now be 
described. 

At a time of transmitting the IP packet (program guide 
packet) toward the video terminal 106, the guide server 102 
applies the ATM-ARP inside the intra-station ATM back- 
bone network 110. Note that the ATM-ARP server is not 
shown in the figures. 

Assuming that the IP address of the video terminal 106 is 
Nb. 1, this video terminal 106 belongs to the IP subnet Nb 
rather than the IP subnet Na inside the CATV station, so that 
this resolution address (ATM address) is going to be the 
address of a router pointing toward the IP subnet Nb, that is, 
the address (ATM address) of the cell switch router 103. 

When it is detected that the ATM connection pointing 
toward the resolution ATM address is already set up (VC 
501), the guide server 102 transmits that IP packet through 
this VC 501. 
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The cell switch router 103 receives this IP packet through 
the default VC 501. 

FIG. 6 shows an exemplary internal configuration of the 
cell switch router 103. As shown in FIG. 6, the cell switch 
router 103 comprises an IP/FANP processing and switch 5 
control unit 601 and an ATM switch unit 602. 

The IP/FANP processing and switch control unit 601 has 
a function for processing the received IP packet or FANP 
packet, and a function for controlling the setting of the ATM 
switch unit 602 according to the FANP processing result. 10 
Note that, among the VCs from the connected ATM network, 
for each of the VCs 501 and 502 which is the default VC set 
up from the beginning for the purpose of IP packet transfer, 
a VC terminal point is always the IP/FANP processing and 
switch control unit 601 inside this cell switch router 103. 15 

The ATM switch unit 602 comprises an ATM switch. 
Among output ports of the ATM switch, at least one is set at 
the IP/FANP processing and switch control unit 601. 

Here, the setting is made so that the IP packet transmitted 
through the default VC will be always forwarded to the IP 20 
processing unit (IP/FANP processing and switch control unit 
601) of the nodes at two ends of that default VC. 

When it is confirmed that the received IP packet is 
destined to the video terminal 106 (by confirming that the 
destination IP address of this IP packet is the IP address Nb. 25 
1 of the video terminal 106), the IP processing unit (IP/ 
FANP processing and switch control unit 601) of the cell 
switch router 103 carries out the routing according to the 
internal IP routing table so as to determine the output 
physical port. 30 

At the output physical port, the cell switch router 103 
carries out the ATM-ARP with respect to the access ATM 
network 111 so as to determine the VC for transmitting this 
IP packet. Note that, in FIG. 1, the ATM-ARP server to be 35 
used here is also not shown. 

The ATM-ARP is carried out with respect to the entire 
access ATM network 111, and eventually the ATM address 
of the NIU 104 will be resolved. 

The ATM address to be resolved here is that of the NIU 40 

104 and not that of the video terminal 106. Namely, this 
address resolution is the proxy resolution, that is, the deputy 
resolution. In a case where the ATM network and the other 
network (such as the Ethernet or the 1394 bus 112 or 113 of 
this embodiment) are inter-connected, the address to be 45 
resolved in response to the address resolution request from 
inside the ATM network should be an ATM address, but a 
resolution target terminal may not necessarily be present on 
the ATM network, so that the ATM address of the NIU 104 
will be resolved in this case. 50 

In the system of this embodiment, as will be described 
below, the cell switch router 103, the NIU 104 and the 1394 
gateway 105 are the FANP nodes, so that the ARP is 
terminated once at each of these nodes and the responded by 
proxy. Namely, the address resolution is carries out sequen- 55 
tially in time series as shown in FIG. 7. (Step S701): The 
address resolution request for the address of the video 
terminal 106, from the cell switch router 103 to the access 
ATM network 111. 

(Step S702): The address resolution request for the 60 
address of the video terminal 106, from the NIU 104 that 
received the address resolution request of the step S701 to 
the first 1394 bus 112. 

(Step S703): The address resolution request for the 
address of the video terminal 106, from the 1394 gateway 65 

105 that received the address resolution request of the step 
S702 to the second 1394 bus 113. 
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(Step S704): The address resolution from the video ter- 
minal 106 to the 1394 gateway 105 (where the resolved 
address is the 1394 address of the video terminal 106). 

(Step S705): The address resolution from the 1394 gate- 
way 105 to the NIU 104 (where the resolved address is the 
1394 address of the 1394 gateway 105). (Step S706): The 
address resolution from the NIU 104 to the cell switch router 
103 (where the resolved address is the ATM address of the 
NIU 104). 

When the above procedure is finished, the IP packet 
transmission sequence is carried out (steps S707, S708 and 
S709). 

The procedure shown in FIG. 7 is a scheme in which the 
address resolution is carried out sequentially from an end, 
and the IP packet transmission is started at a timing where 
all the datalink layer addresses are resolved. However, it is 
also possible to use a scheme as shown in FIG. 8 in which 
the address resolution is carried out hop by hop, and the IP 
packet is forwarded sequentially every time the address is 
resolved. 

Now, according to the resolved ATM address (the ATM 
address of the NIU 104), the cell switch router 103 checks 
whether there is an ATM-VC (a default VC 901) that is 
established with respect to this ATM address or not. Here, if 
it is not established yet, it is established, as indicated in FIG. 
9. 

Thereafter, the cell switch router 103 transmits the IP 
packet through the VC 901, and this IP packet reaches to the 
NIU 104. 

FIG. 10 shows an exemplary internal configuration of the 
NIU 104. As shown in FIG. 10, the NIU 104 comprises an 
ATM physical layer processing unit 1001, an ATM/AAL 
processing unit 1002, a first MUX/DEMUX 1003, an 
IP/FANP processing unit 1004, a second MUX/DEMUX 
1005, a 1394 link processing unit 1006, a 1394 physical 
processing unit 1007, an ATM/1394 transfer unit 1008, an 
ATM control unit 1009, and a 1394 control unit 1010. 

The ATM physical layer processing unit 1001 has a 
function for terminating the ATM transmission path from the 
external, carrying out the ATM physical layer processing, 
and forwarding the ATM cell to the neighboring ATM/AAL 
processing unit 1002, and a function for applying the ATM 
physical layer processing with respect to the ATM cell flow 
from the ATM/AAL processing unit 1002 and transmits it to 
the external. 

The ATM/AAL processing unit 1002 applies the ATM 
layer processing and the AAL processing to the ATM cell 
flow received from the ATM physical layer processing unit 
1001, takes out the AAL-SDU (AAL Service Data Unit: IP 
packet, MPEG frame, etc.), and transmits it to the IP/FANP 
processing unit 1004, the ATM/1394 transfer unit 1008, or 
the ATM control unit 1009 (in a case of the signaling packet, 
etc.) through the first MUX/DEMUX 1003, by referring to 
the VCI value, according to the mechanism to be described 
below. Also, the ATM/AAL processing unit 1002 has a 
function for assembling ATM cells by applying the AAL 
(ATM Adaptation Layer) processing to data (IP packet, 
MPEG frame, etc.) from the first MUX/DEMUX 1003 and 
assembling ATM cells, and transmitting them to the neigh- 
boring ATM physical layer processing unit 1001 by applying 
the ATM layer processing. 

The first MUX/DEMUX 1003 has a function for distrib- 
uting data from the ATM/AAL processing unit 1002 into the 
IP/FANP processing unit 1004, the ATM/1394 transfer unit 
1008, and the ATM control unit 1009, according to the VCI 
value, and a function for collecting data from the IP/FANP 
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processing unit 1004, the ATM/1394 transfer unit 1008, and 
the ATM control unit 1009 into the ATM/AAL processing 
unit 1002. 

The IP/FANP processing unit 1004 has a function for 
terminating the IP packets or the FANP packets transmitted 5 
from the ATM side or the 1394 side, and applying the IP 
processing and the FANP processing. Hence, the IP packets 
(including the FANP packets) transmitted through the 
default VCs (the asynchronous channels or asynchronous 
writes for the 1394 side as described below) from the ATM 1Q 
side and the 1394 side will be forwarded to this IP/FANP 
processing unit 1004. The IP/FANP processing unit 1004 
also has a function for carrying out a series of ARP proce- 
dures such as the address resolution from the IP address to 
the datalink address (the ATM address, the 1394 address). 

At this IP/FANP processing unit 1004, the packet routing 
processing (a processing for determining the physical port to 
which the IP packet is to be transmitted) is carried out 
according to the destination IP address of the IP header, but 
unlike the general router, the so called IP routing protocol 
processing is not carried out at this part. 

The second MUX/DEMUX 1005 has a function for 
collecting data from the IP/FANP processing unit 1004 and 
the ATM/1394 transfer unit 1008 into the neighboring 1394 
link processing unit 1006, and a function for distributing 25 
data from the 1394 link processing unit 1006 into the 
IP/FANP processing unit 1004 and the ATM/1394 transfer 
unit 1008, by referring to the channel number, etc. 

The 1394 link processing unit 1006 and the 1394 physical 
processing unit 1007 carry out the link layer processing and 30 
the physical layer processing of the IEEE 1394, respectively. 
Namely, they provide a function for receiving data from the 
second MUX/DEMUX 1005 at the 1394 link processing unit 
1006, forming 1394 frames from it, and transmitting them to 
the 1394 link, in cooperation with the 1394 control unit 1010 35 
described below, and a function for applying the respective 
1394 layer processings to 1394 frames (containing both 
isochronous ones and asynchronous ones) from the 1394 
link in cooperation with the 1394 control unit 1010, and 
transmitting them to the second MUX/DEMUX 1005. 40 

The ATM/1394 transfer unit 1008 has a function for 
setting data from the ATM side and the 1394 side into 
conformity with the respective formats, carrying out the 
datalink conversion, and forwarding them. The data that 
pass through here are going to flow between the ATM side 45 
and the 1394 side without passing through the IP/FANP 
processing unit 1004 described above. Hence, the data 
forwarding without the IP/FANP processing by the IP/FANP 
processing unit 1004 can be realized directly through this 
ATM/1394 transfer unit 1008, according to the VPI/VCI of 50 
the ATM or the channel number or the destination address of 
the specific register offset of the 1394, regardless of the type 
of information such as IP packet, MPEG frame, etc., so that 
a considerable simplification of processing and improve- 
ment of processing time can be expected. It also becomes 55 
possible to reduce the processing of the IP/FANP processing 
unit 1004. Here, the register offset is a region that can be 
allocated node by node, which is given by the last 48 bits 
address space of the IEEE 1394 address mapping. 

The ATM control unit 1009 carries out the control of the 60 
ATM related part, the signaling processing, etc. 

The 1394 control unit 1010 mainly carries out the IEEE 
1394 transaction layer processing and the serial bus man- 
agement. The 1394 control unit 1010 has a function for 
carrying out data exchange with the 1394 link processing 65 
unit 1006 by applying the above processing, for the neces- 
sary data to/from the IP/FANP processing unit 1004. 
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Now, the procedure according to FIG. 7 will be described. 

The setting is made in advance at the NIU 104 so that, 
among data entered from the default VC (901 of FIG. 9) 
established by the ATM side, the received IP packets will be 
forwarded to the IP/FANP processing unit 1004 provided 
therein. 

At first, the NIU 104 (actually not only the NIU 104 but 
also the FANP nodes such as the 1394 gateway 105) has a 
routing table as shown in FIG. 11 therein, by which an 
information as to which IP terminal exists at the physical 
port of which direction is provided. This is realized in a form 
of providing a routing table at a time of carrying out the 
source routing for each IP terminal (i.e., an entry is regis- 
tered in the routing table for each IP address one by one). It 
is also possible to realize it similarly as the learning bridge 
so that whenever an IP address which is not yet registered in 
the routing table is detected, such an IP address is registered 
into the routing table sequentially. It is also possible to 
realize it such that an IP address for which the passing of a 
IP packet cannot be detected for a certain period of time will 
be deleted from the routing table. 

Now, the processing procedure at the step S701 of FIG. 7 
will be described. 

As shown in FIG. 12, at the IP/FANP processing unit 1004 
of the NIU 104, when it is confirmed that the received packet 
is the ARP request (step S1201), that the ARP requested IP 
address is not the own IP address (step S1202), and that this 
IP address is not registered in the routing table provided 
therein (step S1203), this ARP request is forwarded to the 
other physical port provided therein, such as the physical 
port of the first 1394 bus (network) 112 of FIG. 1 in this 
embodiment, for example. At this point, the own (NIU 
104's) 1394 address is written into the source address of the 
ARP request packet to be transmitted. 

FIG. 13 shows one exemplary frame/packet format for the 
ARP request to be transmitted from the NIU 104 to the first 
1394 bus 112. In this way, the ARP request is transmitted to 
the asynchronous channel, i.e., 902 of FIG. 9, in a form of 
having the ARP packet encapsulated within the 1394 frame. 

This ARP request is transmitted to be broadcasted to the 
first 1394 bus 112, so that it is transmitted with the desti- 
nation ID of the 1394 frame in a form of "bus ID=local bus, 
physical ID=broadcast" or "bus ID=ID of the bus it belongs 
to, physical ID=broadcast" or "channel number=assigned 
asynchronous stream channel". The own node ID is entered 
into the source ID. Note that, in a case where the 1394 buses 
are inter-connected through the 1394 bridge which is 
expected to be standardized in future at the IEEE, it is also 
possible to consider a method for activating the ARP by 
using the destination ID in a form of "broadcast bus ID" by 
which it is transmitted toward all the 1394 buses, instead of 
using the method here, within the 1394 part. In this case, the 
destination 1394 address is directly resolved so that the 
reservation of the isochronous channel up to the destination 
terminal may be made by the internal protocol (such as IEC 
61663, for example) of the 1394. 

Returning to the description of FIG. 13, in the 1394 data 
portion, the ARP packet is entered into a region following 
the LLC/SNAP region. For the ARP packet to be 
encapsulated, an IEEE 1394 number is entered as the 
hardware type, an IP is entered as the protocol type, and the 
length indication and the fact that this packet is the ARP 
request are described in the ARP header. In addition, in the 
data portion, it is also possible to describe the own two 1394 
addresses, that is, an ID called EUI64 which is unchanged by 
the bus reset (which is the ID to be imprinted at a time of 
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shipment by the hardware vender) and an address in the 
1394 address space at that point (a node ID and a memory/ 
register address). For example, in a case of the NIU 104, 
EUI64 will be E4, and the node ID will be (Bb, 2). 

Moreover, the own (NIU 104's) IP address is also 5 
described. Here, a dummy value is entered for the unre- 
solved destination 1394 address, so that only the destination 
IP address (resolution requested IP address Nb. 1) is entered. 

The 1394 frame as shown in FIG. 13 is transmitted to the 
first 1394 bus 112 through the asynchronous channel. This 
frame will be received by all the nodes which are connected 
to the first 1394 bus 112. Among them, a terminal which 
cannot understand the LLC/SNAP as well as a terminal 
which does not have the IP processing function and the 
FANP processing function will discard this frame immedi- 
ately. Even at a terminal which has the IP processing 
function, if this terminal does not have the router function or 
the FANP function and the own IP address is not the 
resolution requested IP address of the ARP, this frame will 

20 

be ignored. 

At the first 1394 bus 112, there is no IP terminal which has 
the IP address (Nb. 1), while the 1394 gateway 105 has the 
FANP function. 

FIG. 14 shows an exemplary internal configuration of the 25 
1394 gateway 105. As shown in FIG. 14, the 1394 gateway 
105 comprises a first 1394 physical processing unit 1401, a 
first 1394 link processing unit 1402, a first MUX/DEMUX 
1403, an IP/FANP processing unit 1404, a second MUX/ 
DEMUX 1405, a second 1394 link processing unit 1406, a 30 
second 1394 physical processing unit 1407, a 1394 switch 
unit 1408, a first 1394 control unit 1409, and a second 1394 
control unit 1410. 

The first 1394 physical processing unit 1401, the first 
1394 link processing unit 1402, and the first 1394 control 35 
unit 1409 provide the physical layer, link layer, and the 
transaction layer/serial bus management functions of the 
IEEE 1394 on the first 1394 bus 112 side, so as to carry out 
the data forwarding from the isochronous channel to the 
asynchronous channel with respect to the IP/FANP process- 40 
ing unit 1404 or the 1394 switch unit 1394 bidirectionally, 
according to the channel number of the 1394 or the desti- 
nation ID or the destination ID with the specific register 
offset, through the first MUX/DEMUX 1403. 

45 

The second 1394 physical processing unit 1407, the 
second 1394 link processing unit 1406, and the second 1394 
control unit 1410 also provide the similar functions on the 
second 1394 bus 113 side. 

The IP/FANP processing unit 1404 has the same functions 50 
as the IP/FANP processing unit 1004 in the NIU 104 of FIG. 
10 as described above. 

The 1394 switch unit 1408 is a device for carrying out 
data exchange directly among plural 1394 ports, without 
using the processing at the IP/FANP processing unit 1404, 55 
between the first MUX/DEMUX 1403 and the second 
MUX/DEMUX 1405. This 1394 switch unit 1408 plays a 
role of buffer in a case of transferring from one 1394 bus to 
another 1394 bus. Also, whenever necessary, this 1394 
switch unit 1408 carries out the processing like the 60 
re-stamping of the timestamp of the MPEG stream, for 
example. In such a case, there is provided a correspondence 
table as shown in FIG. 19 for directly indicating a corre- 
spondence of the channel number or the destination address 
with the specific register offset of the 1394 bus on one side 65 
with the attribute, the destination physical port, and the 
channel number after conversion, etc. 
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Next, the processing procedure of the step S702 of FIG. 
7 will be described. 

Here, the setting is also made in advance at the 1394 
gateway 105 so that, the IP packet arrived at the 1394 
gateway 105 will be forwarded to the IP/FANP processing 
unit 1404 provided therein, after receiving the LLC/SNAP 
analysis. 

Similarly as in FIG. 12, at the IP/FANP processing unit 
1404 of the 1394 gateway 105, when it is confirmed that the 
received packet is the ARP request, that the ARP requested 
IP address is not the own IP address, and that this IP address 
is not registered in the routing table provided therein (steps 
S1201 to S1203), this ARP request is forwarded to the other 
physical port provided therein, such as the physical port of 
the second 1394 bus 113 in this embodiment. At this point, 
the own (1394 gateway 105's) 1394 address E2/(Ba, 2) on 
the second 1394 bus 113 side is written into the source 
address of the ARP request packet to be transmitted. 

This ARP request is also broadcasted on the second 1394 
bus 113. The video terminal 106 which received this ARP 
request recognizes that it is the ARP request destined to 
itself, and returns the ARP response (step S704 of FIG. 7). 

At this point, as shown in FIG. 15, the ARP response 
packet is generated by interchanging the source address and 
the destination address within the ARP packet and entering 
the own IP address (Nb. 1) and 1394 address (El/Ba, 1). 
Then, the 1394 frame is generated by setting the destination 
address of (Ba, 2), i.e., that of the 1394 gateway 105, and this 
1394 frame is transmitted to the asynchronous channel or 
asynchronous write (903 of FIG. 9) of the second 1394 bus 
113. 

When this 1394 frame is received, the 1394 gateway 105 
registers that the IP terminal Nb. 1 exists on the second 1394 
bus 113 side into the internal routing table, and registers the 
IP address (Nb. 1) of the video terminal 106 as well as the 
table of correspondence with the 1394 address as shown in 
FIG. 11 into the internal ARP table (steps S1205 to S1206 of 
FIG. 12). Here, the ARP table and the routing table may be 
formed integrally, and FIG. 11 shows the integrally formed 
one. 

The 1394 gateway 105 has already recognized that the 
ARP request with respect to the video terminal 106 has come 
from the NIU 104 of the first 1394 bus 112 side, so that the 
1394 gateway 105 continues to return the ARP response to 
it (step S705 of FIG. 7 and step S1207 of FIG. 12). At this 
point, the response 1394 address is answered as the 1394 
address (E3/Bb, 1) of the 1394 gateway 105. In other words, 
this is also the deputy response. 

Similarly, the NIU 104 also transmits the deputy response 
for the ARP (in which the NIU 104' s own ATM address Ab. 
1 is described as the resolved ATM address) to the cell 
switch router 103 through the access ATM network 111 
(steps S706 of FIG. 7 and step S1207 of FIG. 12). At this 
point, the VC 901 is used. 

At this point, at the 1394 gateway 105, the fact that the IP 
address (Nb. 1) of the video terminal 106 exists on the 
second 1394 bus 113 side is registered in the internal routing 
table, and its 1394 address (the 1394 address (El/Ba, 1) of 
the video terminal 106) is registered in the internal ARP 
table. Also, at a time of the ARP request packet processing, 
the IP address Nb. 3 of the NIU 104 and its 1394 address 
(E4/Bb, 2) are also registered in the routing table and the 
ARP table, respectively on the first 1394 bus 112 side (see 
FIG. 3). 

Also, at the NIU 104, the fact that the IP address (Nb. 1) 
of the video terminal 106 exists on the first 1394 bus 112 side 
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is registered in the internal routing table, and as its 1394 
address, the 1394 address of the 1394 gateway 105 (the 1394 
address (E3/Bb, 1) on the first 1394 bus 112 side) is 
registered in the internal ARP table because of the deputy 
response. Also, at a time of the ARP request packet 5 
processing, the IP address Nb. 4 of the cell switch router 103 
and its ATM address are registered in the routing table and 
the ARP table respectively, on the access ATM network 111 
side (see FIG. 3). 

Also, at the cell switch router 103, the fact that the IP 1° 
address (Nb. 1) of the video terminal 106 exists on the access 
ATM network 111 side is registered in the internal routing 
table, and as its ATM address, the ATM address Ab. 1 of the 
NIU 104 is registered in the internal ARP table because of 
the deputy response (see FIG. 3). At this point, it becomes 15 
possible for the cell switch router 103 to transmit the IP 
packet destined to the video terminal 106. Namely, the cell 
switch router 103 transmits this IP packet through the default 
VC 901 (which will be established if not already established 
at this point) that is established between the NIU 104 and the 20 
cell switch router 103. 

The default VC is established to be connected to the 
IP/FANP processing unit 1004 of the NIU 104. 

When this IP packet reaches to the NIU 104, it is 
conveyed to the IP/FANP processing unit 1004. Here, the 
IP/FANP processing unit 1004 recognizes that the destina- 
tion IP address of Nb. 1 exists on the first 1394 bus 112 side 
by referring to the routing table, and recognizes its 1394 
address (actually the 1394 address Bb. 1 of the 1394 
gateway 105) by referring to the internal ARP table, so that 
the IP/FANP processing unit 1004 encapsulates this IP 
packet within the 1394 frame destined to the 1394 gateway 

105 and transmits this 1394 frame to the first 1394 bus 112 
through the asynchronous channel. ^ 

FIG. 16 shows a format of the IP packet transmitted on the 
1394 bus. As shown in FIG. 16, the IP packet is basically 
transmitted to the asynchronous write of the 1394, and 
encapsulated within the asynchronous frame of the 1394. 

Because of the setting made in advance according to 40 
which the IP packets and FANP packets that arrive at the 
1394 gateway 105 through the- asynchronous channel or 
asynchronous write of the 1394 are to be connected to the 
IP/FANP processing unit 1404 upon referring to the LLC/ 
SNAP header, when this IP packet arrives at the 1394 45 
gateway 105, it is conveyed to the IP/FANP processing unit 
1404. Here, the IP/FANP processing unit 1404 recognizes 
that the destination IP address of Nb. 1 exists on the second 
1394 bus 113 side by referring to the routing table, and 
recognizes its 1394 address (Ba, 1) by referring to the 50 
internal ARP table, so that the IP/FANP processing unit 1404 
encapsulates this IP packet within the 1394 frame destined 
to the video terminal 106 and transmits this 1394 frame to 
the second 1394 bus 113 through the asynchronous channel. 

In this manner, the IP packet reaches to the video terminal 55 

106 (steps S707 to S709 of FIG. 7 and step S401 of FIG. 4). 
Thereafter, the packet destined to the video terminal 106 

that is transmitted from the guide server 102 can be routed 
to the video terminal 106 without requiring the ARP proce- 
dure. 60 

At the video terminal 106, the program guide transmitted 
through these IP packets is displayed through the browser on 
the video terminal 106. The user makes the request for a 
desired program through this browser. This request is also 
made by using the IP/HTTP (step S402 of FIG. 4). Of 65 
course, there is no need for the user to be conscious of facts 
like what communication protocol is being used. 
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Thereafter, various control procedures are carried out in 
order to carry out the video service such as the user 
authentication, the charging procedure, etc., between the 
guide server 102 and the user (video terminal 106) (step 
S403 of FIG. 4). These control procedures are also carried 
out by using IP/HTTP. 

When these procedures are finished, the operation pro- 
ceeds to a procedure for the purpose of video delivery. First, 
a control signal for program transmission is transmitted from 
the guide server 102 to the video server 1-1 (step S404 of 
FIG. 4). This control signal exchanges the basic information 
concerning the video transmission such as which program is 
transmitted for how long and to whom. This control signal 
exchange is carried out through the default VC 203 between 
the guide server 102 and the video server 101. This operation 
may be realized through the CGI and the like of the guide 
server. There is also a case in which the procedure is carried 
out directly with respect to the video server 1-1 by using the 
language such as JAVA. 

After that, the exchanges for procedures that should be 
done prior to the video transmission are carried out between 
the video server 101 and the video terminal 106. For 
example, the confirmation of the coding scheme, the con- 
firmation of the reception possible bandwidth value, etc., are 
carried out (step S405 of FIG. 4). These exchanges may be 
carried out through IP/HTTP similarly as described above. 
When the agreement between the video server 1-1 and the 
video terminal 106 is made, the operation proceeds to a 
procedure for establishing a datalink connection for guar- 
anteeing the bandwidth from the video server toward the 
video terminal. 

Next, this procedure will be described with references to 
FIG. 17 and FIG. 18. 

Consider a case of deliverying video by a certain band- 
width (4 Mbps, for example) with respect to the video 
terminal 106 (IP address Nb. 1). The video server 101 carries 
out the address resolution for the IP address Nb. 1 (step 

51701) , and then carries out the ATM call set up between the 
video server 101 and the cell switch router 103 so as to 
establish an ATM connection having the bandwidth of 4 
Mbps between the video server 101 and the cell switch 
router 103 that corresponds to the resolved address (step 

51702) . 

Here, for the detailed parameters required in a case of the 
call set up, appropriate values are set up in advance at the 
video server side, and these values are to be utilized as they 
are. 

When the call set up is completed and the ATM connec- 
tion 2101 of 4 Mbps is established between the video server 
101 and the cell switch router 103, the video server 101 
starts the processing determined by the FANP by using this 
ATM connection 2101. 

The datalink connection established in this manner for the 
purpose of some specific flow transmission between the 
FANP nodes will be called a dedicated datalink connection. 

The FANP is a protocol for notifying (ID of) the connec- 
tion with the datalink and a relation with respect to the 
information to be sent through that connection to the neigh- 
boring node. In the following, this procedure will be 
described in detail. Note that the present invention uses the 
FANP function which is modified from the conventional 
FANP function, and such a modified FANP function will be 
referred to as an extended FANP function hereafter. In the 
following, the detailed descriptions will be given for such 
modified portions. 

At the step S1703 of FIG. 17, first, the video server 101 
exchanges the VCID exchange messages through the estab- 
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lished ATM connection 2102 as shown in FIG. 21. Through 
this message exchange, the devices on both ends share the 
meaning of the VCID value (which will be described 
below). This operation is carried out through the exchange 
of the VCID exchange messages of the FANP (see FIG. 22). 5 

FIG. 20 shows an exemplary format of a message to be 
exchanged here. This message format is almost the same as 
the format of the ARP packet in the ATM-LAN. The 
hardware type is set to be ATM, the protocol type is set to 
be IP, the sender IP address is set to be the IP address of the 10 
video server 101, the target IP address is set to be the IP 
address of the video terminal 106, and the VCID (Virtual 
Connection ID) is set to be a globally unique address (MAC 
address of the ATM board) of the video server 101 and a 
sequence number appropriately determined by the video 15 
server 101. 

The VCID is an identifier that can be commonly recog- 
nized at both ends of the VC, which is provided because the 
VPI/VCI is generally different at both ends of the VC in the 
ATM. 20 

Also, as the VCID exchange messages, ACK and NACK 
are provided, and they are to be distinguished by the 
operation code. This ACK/NACK is sent through the default 
VC 502 as shown in FIG. 22. Here, when ACK is returned, 25 
it implies that the agreement on the VCID value is made 
between the devices at both ends. When NACK is returned, 
it implies that no agreement is made. 

In a case where the FANP node is a router, the ACK 
message is returned by simply changing the operation code 30 
value. A case where the FANP node is not a router will be 
described below. 

When the agreement on the VCID is made, the video 
server 1-1 starts the exchange of the flow exchange message 
next as indicated in FIG. 22. 35 

In the present invention, the reservation of the dedicated 
datalink connection is requested to the next hop node 
through this flow exchange message. Namely, the informa- 
tion on the destination IP address, a desired bandwidth to be 
reserved, the communication attribute, etc. are attached to 40 
this flow exchange message and this flow exchange message 
is sent to the next hop FANP node, so as to request the next 
hop FANP node to set up an end-to-end connection con- 
nected to the target terminal. 

The FANP node reserves the necessary datalink connec- 
tion (dedicated datalink connection) that satisfies the 
sequentially requested conditions between the neighboring 
nodes, and relates this dedicated datalink connection with 
the dedicated datalink connection notified from the previous 
hop. This relating operation is carried out on the VCI table. 50 
After this relating operation is carried out, values of the 
reserved bandwidth, the attribute (indicating that data flow- 
ing therethrough is the MPEG video, etc.), the output port, 
the output header (VPI/V CI), etc., can be ascertained implic- 
itly by simply referring to the value of the VPI/VCI. 55 

This operation is carried out sequentially up to the des- 
tination terminal (the video terminal 106 in this 
embodiment), and eventually the end-to-end connection is 
established. 

6u 

FIG. 23 shows an exemplary format of the flow exchange 
message. By the operation code portion of this flow 
exchange message, the type of the flow exchange message 
is indicated. 

The flow exchange message includes an offer message 65 
(operation code=l), a re-direct message (operation code=2), 
an error message (operation code=3), a release message 
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(operation code=4), a release ACK message (operation 
code=5), and a pending message (operation code=6). For 
details, see Japanese Patent Application No. 7-58196 (1995). 

In this embodiment, the value "1" is fixedly entered into 
the VCID type. When the VCID type=l, an ESI (End System 
ID, which is usually the MAC address of the end system) 
and a sequence number are entered into the VCID. 

This VCID has the meaning that there is an agreement that 
"let's call this VC (isochronous channel) by the VCID value 
at the FANP nodes of both ends". (Note that, when a 
different scheme for expressing the VCID appears, another 
value will be allocated.) 

The flow ID type specifies a scheme for expressing the 
flow ID. Here, the flow is a specific meaningful information 
(a specific set of mutually meaningful information transmit- 
ted toward a specific destination from a specific source). The 
flow ID is an ID for uniquely identifying a certain flow. This 
flow ID will be described in further detail below. 

The other parameters are optional, and given by TLV 
(Type, Length, Variable) based descriptions. In this 
embodiment, the communication quality information, the 
end-to-end ACK (e-ACK), and the communication attribute 
are entered there. 

To the communication quality information, a value of 
communication quality to be required to the connection to be 
established will be entered. For this value, a T-spec value of 
int-serv of IETF may be entered, for example. In this 
embodiment, it suffices to enter a value which indicates 4 
Mbps which is a value of the required bandwidth. 

The e-ACK flag is a flag for requesting the transmission 
of an ACK signal from the final point to the transmission 
point. This end-to-end ACK signal will provide a clue for the 
transmission device (the video server 101 in this 
embodiment) to ascertain whether the connection establish- 
ing up to the final point (the video terminal 106 in this 
embodiment) has been successful or not. 

The video server 101 sends the offer message among the 
flow exchange messages to the cell switch router 103 which 
is the neighboring FANP node, as indicated in FIG. 22. This 
message sending is carried out through the default VC 502 
between the video server 101 and the cell switch router 103. 

This message contains the operation code indicating that 
it is the offer message, the VCID, the flow ID, the commu- 
nication attribute, the communication quality (bandwidth 
information), and the e-ACK flag, as indicated in FIG. 24. 
The last three of these are options expressed in the TLV 
format. 

To the VCID, the MAC address of the video server 101 
and the sequence number assigned by the video server 101 
are entered. 

To the flow ID, basically a value such as the destination 
IP address is entered, as will be described below. 

To the communication attribute, an indication that the data 
to be transmitted is the MPEG stream is entered. 

The bandwidth information indicates the bandwidth of 
that video stream (4 Mbps in this embodiment), and the 
e-ACK flag is ON because the video server 101 requests the 
end-to-end ACK. 

At the cell switch router 103 which is the neighboring 
FANP node that received this message, the received packet 
is processed by the IP/FANP processing and switch control 
unit 601. 

By looking at the e-ACK flag, it can be understood that 
the transmitting side requests the reservation of the end-to- 
end connection. Therefore, in order to establish the end-to- 
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end connection, the forwarding of the FANP message 
toward the direction of the destination IP address (the video 
terminal 106) and the pending message for the purpose of 
notifying "please wait for awhile until the connection is 
established (or the processing load becomes lower)" to the 
transmitting side (the video server 101) are defined (see FIG. 
25). 

The pending message is transferred after the VCID and 
the flow ID possessed by the corresponding offer message 
are attached thereto. 

At the video server 101 that received the pending 
message, a response to the earlier transmitted offer message 
will be awaited for awhile. 

Also, the cell switch router 103 forwards this FANP 
message toward the direction of the video terminal 106 so as 
to establish the end-to-end datalink connection, and tries to 
transmit the offer message toward the direction of the video 
terminal 106. 

At this point, the resolved address of the video terminal 
106 is the ATM address of the NIU 104, so that the ATM 
connection with the bandwidth (4 Mbps) described in the 
offer message is established between the cell switch router 
103 and the NIU 104 (step S1704 of FIG. 17). Namely, as 
shown in FIG. 21, the ATM connection 2102 for video 
transmission is established in addition to the default VC 901. 

When this ATM connection 2102 is established, the cell 
switch router 103 transmits the VCID exchange message 
through the ATM connection 2102 similarly as in a case of 
the video server 101 (step S1705 of FIG. 17). Note that the 
setting is made in advance so that the data transmitted 
through this ATM connection 2102 will be transmitted to the 
IP/FANP processing unit 1004 of the NIU 104. 

At the NIU 104 that received this message, it is ascer- 
tained that the destination IP address of the FANP message 
is not its own, and it is directed to the video terminal 106 (IP 
address=Nb. 1), from this VCID exchange message. Assum- 
ing that the subsequently arriving FANP message (such as 
the offer message) is destined to the IP address (Nb. 1) of the 
video terminal 106, the IP/FANP processing unit 1004 of the 
NIU 104 cannot confirm that this is the FANP packet unless 
the protocol type and the port number of the IP packet are 
checked, so that either the FANP processing cannot be 
carried out or else the protocol type and the port number 
must be checked for all packets destined to the IP/FANP 
processing unit 1004 in order to carry out the FANP pro- 
cessing. 

In order to avoid this, the fact that the neighboring FANP 
node is not the video terminal 106 but the NIU 104 is 
notified to the cell switch router 103 which is the neighbor- 
ing FANP node. To this end, the own IP address (Nb. 3) is 
entered into a field for the target IP address in the VCID 
exchange message, and the propose ACK message is 
returned (see FIG. 20). 

In this way, the cell switch router 103 can ascertain that 
the next hop FANP node is not the video terminal 106 but the 
NIU 104 (IP address=Nb. 3) in the routing path toward the 
video terminal 106, and recognize that it suffices to transmit 
the subsequent FANP message (the FANP message toward 
the video terminal 106) about that VCID value to the NIU 
104. 

After that, the cell switch router 103 transmits the offer 
message of the flow exchange messages to the NIU 104. 
Hence, by the ARP table search, this offer message will be 
transmitted through the default VC 901. The destination IP 
address of this offer message is the IP address Nb. 3 of the 
NIU 104. 
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The NIU 104 can ascertain the final target IP address (the 
IP address of the video terminal 106) by looking at the flow 
ID portion (which will be described below). The others 
including the communication attribute, the communication 
5 quality, the e-ACK flag, etc. are forwarded as they are. 

At the NIU 104 that recognized the need to set up a 
connection of 4 Mbps to the video terminal 106 in this way, 
the fact that the video terminal 106 exists in the direction of 
the first 1394 bus 112 is recognized by referring to the 
1° internal routing table, and the establishing of an isochronous 
channel of 4 Mbps on the first 1394 bus 112 is carried out. 

This operation is done as the NIU 104 appropriately sets 
up the isochronous resource manager register, and sequen- 
tially carries out the reservation of the bandwidth and the 
15 reservation of the channel number (step S1706 of FIG. 17). 

Next, the NIU 104 carries out the sending of the VCID 
exchange message (step S1707 of FIG. 17), and there are 
several methods for realizing this operation. 

The first method is a method in which the earlier acquired 

20 . . 

isochronous channel number is notified to the 1394 gateway 
105 by the protocol of the 1394 itself, and the setting is made 
in advance so that this channel will be connected to the 
IP/FANP processing unit 1404. Else, the setting may be 
made such that the established isochronous channel will be 

25 

connected to the IP/FANP processing unit 1404 by default. 
It is also possible to make the setting in which the fact that 
this is the IP/FANP packet is recognized by referring to the 
LLC/SNAP header, and then this is transferred to the 

3Q IP/FANP processing unit 1404. 

The FANP node may have the setting by which the 
IP/FANP processing unit 1404 distinguishes the input packet 
as either the IP packet or the FANP packet and carries out the 
FANP processing only if it is the FANP packet. 

35 After that, the VCID exchange message as shown in FIG. 
26 is sent to that isochronous channel. At the IP/FANP 
processing unit 1404 of the 1394 gateway 105 that received 
this VCID exchange message, the own IP address (Nb. 2) is 
entered into the ACK message and this ACK message is 

40 returned to the NIU 104 through the asynchronous channel 
or asynchronous write. 

The sequence shown in FIG. 18 shows the sequence 
shown in FIG. 17 in further detail according to the first 
method as described above. 

45 The second method is a method for sending the VCID 
exchange message toward the 1394 gateway 105 by using 
the asynchronous channel or asynchronous write. The 
resolved address of the video terminal 106 is set to be the 
1394 address of the 1394 gateway 105. The setting is made 

50 such that this VCID exchange message reaches to the 
IP/FANP processing unit 1404 of the 1394 gateway 105. 
One method for realizing the above setting is to make the 
setting in advance such that the VCID exchange message 
automatically reaches to the IP/FANP processing unit 1404. 

55 Another method for realizing the above setting is a method 
in which the NIU 104 carries out the RARP and the like from 
the 1394 address of the 1394 gateway 105 to check the IP 
address Nb. 2 of the 1394 gateway 105 in advance, and 
sends the VCID exchange message toward this IP address 

60 Nb. 2. 

The third method is a method for a case in which the 
setting is made in advance such that the message is conveyed 
to the IP/FANP processing unit 1404 by the LLC/SNAP. The 
1394 gateway 105 that received this message attaches the 
65 own IP address to the ACK of the VCID exchange message 
and returns this ACK to the NIU 104, similarly as in a case 
of the NIU 104. In this way, the NIU 104 can also recognize 
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that the next hop FANP node leading to the video terminal 
106 is the 1394 gateway 105 (IP address=Nb. 2), so that it 
becomes possible to send the subsequent FANP packet (flow 
exchange message) with respect to the 1394 gateway 105, 
rather than sending it directly to the video terminal 106. 

The above described is an exemplary case of reserving the 
isochronous channels, but in a case of using the register 
offset in the asynchronous mode, an agreement is made on 
a value of the register offset to be used at a time of 
communication between the NIU 104 and the 1394 gateway 
105. Thereafter, in the FANP message, this register offset 
value is transmitted instead of the isochronous channel 
number. 

The operation at the 1394 gateway 105 after that is the 
similar to the operation at the NIU 104 described above. 
Namely, the flow exchange message is received, and the 
need to establish the reservation of the bandwidth of 4 Mbps 
between the 1394 gateway 105 and the video terminal 106 
is recognized. The pending message is sent to the NIU 104 
which is the previous hop FANP node, while the isochronous 
channel of 4 Mbps and its channel number are reserved on 
the second 1394 bus 113 with respect to the video terminal 
106 (step S1708 of FIG. 17), and the VCID exchange 
message is sent toward the video terminal 106 by the method 
similar to those described above (step S1709 of FIG. 17). 

In response to the VCID message (propose message), if it 
is acceptable, the video terminal 106 returns ACK (propose 
ACK). Then, the flow exchange message of the FANP is 
received through the asynchronous channel or asynchronous 
write, and recognizes that this is a message destined to this 
video terminal 106. The fact that the contained data is the 
MPEG stream can be recognized according to the commu- 
nication attribute field, but this can also be done by the other 
methods. As an example, the video terminal 106 may be 
made so that it is possible to ascertain the attribute of data 
that will be arriving from this channel according to the flow 
ID value. 

For example, this can be realized by implicitly entering an 
information as to which port numbers are the transport 
stream of MPEG2, etc. in advance. Also, as the e-ACK flag 
is erected, the need to transmit the end-to-end ACK message 
indicating that the FANP message was accepted, with 
respect to the transmission terminal (i.e., the video server 
101), can also be recognized. 

When it is acceptable, a re-direct message as shown in 
FIG. 27 is returned to the previous hop 1394 gateway 105 as 
the exchange of the flow exchange message. 

The re-direct message is sent to the 1394 gateway 105 by 
using the asynchronous channel or asynchronous write of 
the second 1394 bus 113. 

As shown in FIG. 27, the re-direct message has values of 
the VCID and the flow ID entered therein, so that the 1394 
gateway 105 that received this message can recognize the 
offer message that was earlier transmitted from it to which 
this re-direct message corresponds. 

It is also possible to use a scheme in which the end-to-end 
ACK signal is contained in this re-direct message, and as 
described below, when the FANP node that received this 
end-to-end ACK transmits to the re-direct message to the 
upstream side, that FANP node also transmits this re-direct 
message by erecting the end-to-end ACK signal. 

In this way, it becomes possible to return the end-to-end 
ACK from the final terminal (the video terminal 106 in this 
embodiment) to the transmission terminal (the video server 
101). Note that there is no need to mount this end-to-end 
ACK on every re-direct message, and it is possible to use a 
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scheme in which it is also transmitted to the upstream side 
only when it is received from the downstream side, for 
example. 

The 1394 gateway 105 that received the re-direct message 

5 interprets that the earlier transmitted offer message was 
accepted. At this point, the 1394 gateway 105 recognizes 
that, hereafter, when the MPEG video for example is entered 
from the isochronous channel 2103 of the first 1394 bus 112, 
it is necessary to transmit it further to the isochronous 

10 channel 2104 of the second 1394 bus 113. Consequently, the 
IP/FANP processing unit 1404 makes the necessary setting 
(the initialization of the internal queue, the setting of the 
correspondence table of FIG. 19, etc.) by which the data 
from the isochronous channel 2103 will be forwarded to the 

15 1394 switch unit 1408 at the first MUX/DEMUX 1403, and 
this data will be transmitted at the 1394 switch unit 1408 to 
the second MUX/DEMUX 1405 by applying only the 
datalink layer processing (that is, the switching of the 1394 
frames among the 1394 buses by checking only the channel 

20 number or the destination address with the specific register 
offset). 

In addition, the setting is also made with respect to the 
second MUX/DEMUX 1405 so that this data will be trans- 
mitted to the isochronous channel 2104 of the second 1394 
25 bus 113. 

Moreover, the re-direct message is also transmitted to the 
previous hop NIU 104. 

At this point, when the e-ACK is erected in the re-direct 
30 message from the downstream side, the e-ACK is also 
erected there. 

These steps are repeated up to the video server 101. Note 
that the NIU 104 has the setting (the setting of the corre- 
spondence table for enabling the direct conversion from the 

35 VPI/VCI value of the ATM to the channel number of the 
1394) for the ATM/1394 transfer unit 1008 by which it is 
possible to carry out the data forwarding at the datalink layer 
(without using the processing at the IP/FANP processing 
unit) from the ATM connection 2102 to the isochronous 

40 channel 2103 of the first 1394 bus 112 simply by the datalink 
switching from the ATM to the 1394. 

Also, at the cell switch router 103, the direct ATM layer 
connection (the setting of the VCI table) is made for the 
ATM connection 2101 and the ATM connection 2102 by the 

45 internal ATM switch 602. At this point, all the datalink 
connections from the video server 101 to the video terminal 
106 are established. This is shown in FIG. 28. 

In addition, by the arrival of the end-to-end ACK, it is 
indicated that the video reception preparation is ready at the 

50 video terminal 106 which is the target terminal (step S1710 
of FIG. 17). 

Here, prior to the connection establishing, the video 
server 101 can start transmitting video data to the VC 2101 

55 by which the FANP message exchange was carried out. The 
transmitted video data reaches to the video terminal 106 
basically without receiving any intermediate IP layer 
processing, along the connection of FIG. 28. 

Note that the data to be transmitted can be either raw 

60 MPEG data or MPEG data encapsulated within IP packets 
(that is, the so called MPEG-over-IP). 

In the former case, the MPEG data will be transmitted 
according to the MPEG-over-ATM specification standard- 
ized by the ATM forum (SAAVer. 1 specification) while the 

65 MPEG data are transmitted on the ATM, and according to 
the MPEG-over-1394 specification standardized by the digi- 
tal VTR conference while the MPEG data are transmitted on 
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the 1394. Also, in this case, at the ATM/1394 transfer unit 
1008 of the NIU 104, the transfer and the format conversion 
between the MPEG-over-ATM and the MPEG-over-1394 
will be carried out. In this case, the end-to-end datalink layer 
connection set up for the purpose of the raw MPEG video 5 
data transfer is made by using the FANP. In this case, the 
triggering of these processings can be done by the VPI/VCI 
value which is the datalink layer header. 

As described, according to this first embodiment, the 
following effects can be realized. 10 

(1) Even under the environment in which different types 
of network technologies (datalink technologies) such as 
ATM and IEEE 1394 are mixedly present, it becomes 
possible to carry out the data transfer by establishing the 
end-to-end datalink layer connection. 15 

(2) In a case of carrying out the data transfer at the 
datalink connection point, there is a degree of freedom in 
that it is possible to control the inter-connecting device such 
that the datalinks can be connected directly, without using 
the processing by the IP/FANP processing unit, so that it 20 
becomes possible to carry out the high speed data transfer 
wherever necessary. 

(3) Even if the data to be transmitted is not the IP packet, 
it is possible to realize the route setting for it by using the 
IP/FANP for the control of the connection establishing, so 25 
that it becomes possible to realize any desired data transfer 
with respect to any desired location. 

(4) In the FANP node, the routing protocol such as OSPF 
is not operated unlike the conventional router, so that there 

. . 30 

is basically no need to support the dynamical routing, and 
therefore the processing load is lighter compared with the 
conventional router. 

Now, once the directly connected connections are estab- 
lished as shown in FIG. 28, these end-to-end datalink layer 35 
connections can be maintained fixedly. 

In this case, as long as the explicit connection release 
control message does not come, these connections will be 
continued permanently so that the connections will be 
maintained in a hard state. In this case, at the end of the 40 
communication, the sender, the receiver, or the intermediate 
node transmits the connection release message among the 
flow exchange messages of the FANP, so as to urge the 
connection release to each FANP node. 

Here, the case in which the sender requests the connection 45 
release can arise at the end of the program, or when the 
reserved time is over. Also, the case in which the receiver 
requests the connection release can arise when the user 
wishes to disconnect that connection voluntarily, or due to 
the reception terminal setting (such as the timer reservation). 50 
Also, the case in which the intermediate node requests the 
connection release can arise when a cable disconnection, a 
power supply disruption, etc. is detected at an intermediate 
location. 

As shown in FIG. 29, the connection release is carried out 55 
by the exchange of the release message and the release ACK 
message among the flow exchange messages. 

The node 2901 that carries out the connection release 
transmits the release message to the neighboring FANP node 
2902, and the FANP node 2902 that received this message 60 
transmits the release ACK message. Here, the connection 
release is merely the releasing of the "datalink connections 
inter-connected" state at the FANP node (the releasing of a 
pipe indicated by dashed lines in FIG. 28), and the releasing 
of the VC in the ATM network or the datalink layer 65 
connection such as the isochronous channel in the IEEE 
1394 is not absolutely necessary. 
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When some node receives the connection release request 
from the upstream or downstream side, and Judges that it is 
meaningless to maintain the connection to its downstream or 
upstream side from the overall viewpoint (because the data 
transfer beyond there will be no longer maintained due to 
that connection release), that node will continue to make 
(forward) the connection release request further to its down- 
stream or upstream side. 

Also, as shown in FIG. 30, the connection may be 
maintained in a soft state. In the soft state, the downstream 
node regularly transmits the re-direct message to the 
upstream node so that the upstream node recognizes that the 
downstream node is capable of continuing to receive data at 
a corresponding datalink connection, and continues to send 
data into that datalink connection. This transmission of the 
re-direct message is carried out at the prescribed refresh 
interval as indicated in FIG. 30. Then, when the re-direct 
message did not reach to the upstream node after the 
prescribed refresh period elapsed (a state indicated as 3002 
in FIG. 30), the upstream node judges that the downstream 
node became impossible to receive data at that datalink 
connection so that the upstream node stops the data transfer 
to that datalink connection. 

The downstream node transmits the re-direct message 
regularly to the upstream node as long as data is flowing in 
that datalink connection. The re-direct message is transmit- 
ted at the refresh interval indicated by the offer message. 
When no data is flowing, the re-direct message is not 
transmitted. 

By transmitting the re-direct message in this manner, it is 
possible for the upstream node to confirm that the datalink 
connection (2101, 2102, 2103 or 2104) related to that 
re-direct message is operating normally and that the down- 
stream node is active. 

Here, when the upstream node is broke down for some 
reasons, in order to avoid leaving the downstream node in a 
state of having that datalink connection set up, this datalink 
connection is released from the downstream node when a 
state of having no data flowing in that datalink connection 
continues for a certain period of time at the downstream 
node. 

Also, when the data transferred by that datalink connec- 
tion is the IP packet, in conjunction with the end of the IP 
packet transfer by that datalink connection, it is also possible 
to carry out the switching of that IP packet transfer from that 
dedicated datalink connection to the default VC (default 
channel= asynchronous channel or asynchronous write). 

Next, a method for using the flow ID as described above 
will be described. 

In a case of transmitting the IP packets through the 
datalink layer connections established according to the 
present invention, a typical method is to use the flow ID 
given by "IP address of the transmitting terminal+IP address 
of the receiving terminal" or "IP address of the transmitting 
terminal+port number of the transmitting terminal+IP 
address of the receiving terminal+port number of the receiv- 
ing terminal". 

In a case of entering the IP packets into the datalink layer 
connections which are directly connected by this method, it 
suffices for the intermediate FANP node to distinguish the IP 
flows to be entered by entering only those IP packets which 
have a specific set of "source address+destination address" 
or "source address+source port number+destination 
address+destination port number" among the IP packets. 
Note that this operation may be done by any intermediate 
FANP node (usually a router). Also, this directly connected 
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connections may be interrupted anywhere. As such, what 
value is to be used as the flow ID value can be ascertained 
by each FANP node according to the flow ID type number. 

Next, a case of entering the raw data (such as MPEG data, 
for example) rather than the IP packets into the directly 5 
connected datalink layer connections will be considered. 

First, consider a case of entering "destination IP address+ 
destination port number" as the flow ID. If the both sides of 
the transmitting and receiving terminals acknowledge in 
advance a rule like "when a value in a certain range is used 10 
as a value of the destination port number, raw data rather 
than IP packets will be entered into the directly connected 
datalink layer connections", then by looking at the destina- 
tion port number of the flow ID, the FANP node can 
recognize that data that will subsequently flow in are not the 15 
IP packets. In this case, there may be no need to transmit the 
information regarding the communication attribute. 

Next, consider a case of entering "destination IP 
address+a unique ID determined by the transmitting termi- 
nal" as the flow ID. Here, this "unique ID determined by the 20 
transmitting terminal" is a unique ID that is determined and 
used by the transmitting terminal by attaching some mean- 
ing. Similarly as in the previous case, it is also possible to 
consider a method in which both sides of the transmitting 

• 25 

and receiving terminals acknowledge in advance a rule like 
"when a value in a certain range is used as a value of the 
unique ID, specific raw data will be entered into the directly 
connected datalink layer connections". 

The flow ID will be flowing from each source when the 3Q 
information outputted from two or more sources (which may 
not be outputted simultaneously) are merged at some FANP 
node and outputted at the identical datalink layer connection 
from that FANP node. 

It is also possible to consider a method in which an 35 
identical flow ID can be attached to the information (flow) 
to be entered into that datalink, and used as an identifier by 
means of which the information from different sources can 
be collected into one datalink layer connection. 

This case will be described in detail with reference to FIG. 40 
31, which shows the network that has basically the similar 
configuration as that of FIG. 1 (and therefore the descrip- 
tions of the constituent elements will be omitted here), but 
it differs from the network of FIG. 1 in that a plurality of 
video servers (two video servers 3121 and 3122 in FIG. 31, 45 
for example) are provided. 

The video data delivery from these video servers is also 
controlled by the program guide delivery server (guide 
server) 3102. At this point, the guide server 3102 notifies 
some specific number to either one of the video servers 3121 50 
and 3122 for carrying out the delivery, as a control of the 
video data delivery with respect to the same video terminal 
3106 at the same connection time, in a sense of "use this 
number as the flow ID (or its part)". Here, the video data 
delivery from different video servers at the same connection 55 
time occurs in such a case where a user of the video terminal 
3106 changes the video channel number (program) to be 
watched, or a case in which the different video servers 
provide different programs respectively. 

In such a case, when the plural video servers throw the 60 
identical flow ID (or its part), it becomes possible for the 
FANP node (the cell switch router 3103 in this case) to 
ascertain that both of these flows are to be forwarded to the 
identical datalink connection 3109. Consequently, even in a 
case where the channel switching by the user (that is, the 65 
changing of the video server) occurs, there is no need to 
establish a new datalink layer connection at the downstream 



side of that FANP node (the cell switch router 3103 in this 
case), and it becomes possible to transmit the respective data 
to appropriate datalink layer connections. 

Note that, in this case, when the re-direct message comes 
from the downstream side, there is a need to transmit it to a 
plurality of upstream side FANP nodes (the video servers 
3121 and 3122 in this case) which are related by the FANP. 

Also, it is necessary for a switch that connect the datalink 
layers together (The ATM switch within the cell switch 
router 3103 in this case) to have a connection form of 
multiple-to-one (that is, a form by which data from different 
input datalink connections are to be collectively outputted to 
one output datalink connection). It is also possible to pre- 
suppose that data will not be transmitted from a plurality of 
transmitting terminal simultaneously. 

In addition, a portion described as the 1394 bus in the 
above description may be replaced by 1394 networks inter- 
connected by 1394 gateways or 1394 bridges. 

Moreover, the router has been described above a some- 
thing which is provided at the CATV head-end outside the 
home, but of course it is also possible to place it inside the 
home. 

In this embodiment, the description has been given for an 
exemplary case in which the reservation of the bandwidth 
from the video server 101 to the video terminal 106 is made 
by using the extended FANP. In contrast, it is also possible 
to carry out the bandwidth reservation control in the existing 
router (the cell switch router 103 in this embodiment) by 
using the signaling protocol in the network layer such as the 
RSVP (Resource Reservation Setup Protocol) or ST2 
(Stream Transport Protocol-2), and carry out the bandwidth 
reservation control by using the extended FANP of the 
present invention within the IP subnet, that is, between the 
cell switch router 103 to the video terminal 106. The 
sequence in this case is shown in FIG. 32. 

FIG. 32 shows an exemplary case in which the RSVP is 
used as the signaling protocol in the network layer. Note 
that, in FIG. 32, the detailed message exchanges such as 
those for the propose message and the pending message are 
omitted for simplicity. 

For the bandwidth reservation control among the trans- 
mitting terminal (video server 101), the router (cell switch 
router 103) and the video terminal 106, the signaling pro- 
tocol such as RSVP or ST2 is used, and the bandwidth 
reservation control within the subnet among them is carried 
out by using the extended FANP of the present invention. 
Namely, the extended FANP of the present invention is used 
for the purpose of the datalink connection control between 
the RSVP nodes. By means of this, the existing router 
becomes the de facto standard between the internet routers, 
and the widely used bandwidth reservation protocol between 
the terminal and the router or between one router and 
another such as ST2 or RSVP can be used, so that it becomes 
possible to realize the bandwidth reservation within the 
subnet that has not been used conventionally, in particular 
the bandwidth control in the subnet under the heterogeneous 
environment in which the virtual connection type networks 
are mixedly present, by using the extended FANP of the 
present invention. 

Second Embodiment 

Next, with references to FIG. 33 to FIG. 44, the second 
embodiment of the present invention will be described in 
detail. 

This second embodiment is directed to a communication 
network system formed by two or more 1394 buses, nodes 
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called half gateways which are connected to respective 
buses, and a various type of network for connecting these 
half gateways. 

FIG. 33 shows an exemplary overall configuration of a 
communication network system (a home network system for 5 
connecting various electric devices inside the home, for 
example) according to this second embodiment. As shown in 
FIG. 33, this communication network system comprises a 
transmitting terminal 4001, a first half gateway 4002, a 
second half gateway 4003, a receiving terminal 4004, a first 10 
1394 bus 4011, an Ethernet cable 4012, and a second 1394 
bus 4013. 

Here, it is assumed that the entire system constitutes a 
home network within the same home, similarly as in the first 
embodiment. Consequently, among the devices contained in 15 
this system, those which are the IP nodes are assumed to be 
belonging to the same IP subnet. Here, this IP subnet is 
assumed to have an IP subnet address N, and the IP 
addresses of the nodes are assumed to be N. 1 for the 
transmitting terminal 4001, N. 2 for the first half gateway 20 
4002, N. 3 for the second half gateway 4003, and N. 4 for 
the receiving terminal 4004. 

Also, the 1394 addresses and the Ethernet addresses of 
these nodes are as shown in FIG. 33. 

Each of the transmitting terminal 4001, the first half 25 
gateway 4002, the second half gateway 4003 and the receiv- 
ing terminal 4004 of this embodiment is the FANP node as 
described in the first embodiment which has the extended 
FANP function of the present invention. 

The transmitting terminal 4001 is also the IP terminal as 30 
well, and has functions for exchanging IP packets with the 
receiving terminal 4004 and delivering video with respect to 
the receiving terminal 4004. 

The video delivery may be carried out by mounting the 
video information on the IP packets, or by transmitting the 35 
video data directly into the specified 1394 isochronous 
channel. Further details in this regard will be described 
below. 

The first half gateway 4002 and the second half gateway 
4003 are devices for connecting the 1394 buses together. 
Namely, they are devices to be used in connecting the first 
1394 bus 4011 and the second 1394 bus 4013. Such a 
situation may arise when the first 1394 bus 4011 and the 
second 1394 bus 4013 are far apart from each other so that ^ 
it is difficult to unify them into a single 1394 bus, for 
example. 

Namely, according to the specification of the 1394, it is 
not preferable for the 1394 buses to use a long cable. In such 
a case, the half gateways of the present invention can be 5Q 
connected to the respective 1394 buses and these half 
gateways can be connected together by a dedicated cable, so 
as to realize the connection between the 1394 buses. Further 
details in this regard will be described below. 

The receiving terminal 4004 is also the IP terminal as 55 
well, and has functions for exchanging IP packets with the 
transmitting terminal 4001, and receiving video delivered 
from the transmitting terminal 4001. 

The first half gateway 4002 and the second half gateway 
4003 are connected by the Ethernet cable 4012. Namely, in 60 
this embodiment, the data exchanges between two half 
gateways are to be carried out in terms of the Ethernet 
frames. 

FIG. 34 shows an exemplary internal configuration of the 
half gateway 4002 or 4003. 65 

As shown in FIG. 34, this half gateway comprises a 1394 
physical processing unit 4101, a 1394 link processing unit 
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4102, a 1394 control unit 4103, a first MUX/DEMUX 4104, 
an IP/FANP processing unit 4105, a 1394/Ethernet transfer 
unit 4106, a second MUX/DEMUX 4107, and an Ethernet 
interface unit 4108. 

The 1394 physical processing unit 4101, the 1394 link 
processing unit 4102, and the 1394 control unit 4103 carry 
out the physical layer processing, the link layer processing, 
and the bus management and the transaction layer 
processing, respectively, for the connected 1394 bus (4011 
or 4013), as well as the exchanges of data (PDU from a 
viewpoint of 1394) with the IP/FANP processing unit 4105 
or the 1394/Ethernet transfer unit 4106, using the 1394 
frames to be transmitted or received that are passing through 
the first MUX/DEMUX 4104 and the second MUX/ 
DEMUX 4107. 

The IP/FANP processing unit 4105 has functions for 
carrying out the routing based on the IP address, the routing 
table management, the FANP processing, the ARP 
processing, etc., for the received IP packets, FANP packets, 
ARP packets, etc. 

The 1394/Ethernet transfer unit 4106 has a function for 
attaching a specific Ethernet header to data received from 
the 1394 side, especially data received through the isochro- 
nous channel, by using its isochronous channel number or 
the specific register offset on the destination address as a key, 
and transmitting it to the Ethernet side, and a function for 
transmitting data received from the Ethernet side to a 
specific isochronous channel or the specific address offset on 
the 1394 side by using its header information as a key. 
Namely, the data forwarding at this processing unit is carried 
out by using only the datalink layer processing without using 
the IP layer processing. 

For example, a table of correspondence between the MAC 
address value and the channel number of the isochronous 
channel of the 1394 bus is produced in a form of a corre- 
spondence table as shown in FIG. 35 (in a case of transmit- 
ting data received from the 1394 side to the Ethernet side) 
or FIG. 36 (in a case of transmitting data received from the 
Ethernet side to the 1394 side), for example. Here, the 
mapping for each correspondence table is made by the 
IP/FANP processing unit 4105. A similar correspondence 
table can be configured between the MAC address value and 
the 1394 destination address with a specific register offset 
value. 

The Ethernet interface unit 4108 is an interface with 
respect to the physically connected Ethernet, and carries out 
the encapsulation and decapsulation of data to be exchanged 
with the second MUX/DEMUX 4107 and the Ethernet 
frames. 

Next, for an exemplary case of transmitting video from 
the transmitting terminal 4001 to the receiving terminal 
4004, the operation sequence in time order will be described 
with references to FIG. 37 and FIG. 38. 

FIG. 37 shows a sequence for the ARP (Address Reso- 
lution Protocol). 

First, the transmitting terminal 4001 transmits the ARP 
request packet to the first 1394 bus 4011 in order to carry out 
the address resolution for ascertaining the datalink layer 
address of the receiving terminal 4004 from its IP address 
(step S4201). As described in the first embodiment, this ARP 
request is broadcasted on the local bus (that is, the first 1394 
bus 4011). 

The first half gateway 4002 which is the FANP node that 
received this ARP request forwards this ARP request to the 
Ethernet cable 4012, upon confirming that the requested 
address is not the own address and that another port (that is, 
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the Ethernet cable 4012) different from the port through 
which this ARP is entered (that is, the first 1394 bus 4011) 
is connected (step S4202). Here, the destination Ethernet 
address is the Ethernet broadcast address. 

The second half gateway 4003 that received this ARP 5 
request also forwards this ARP request to the second 1394 
bus 4013 through a procedure in which the procedure of the 
first half gateway 4002 is reversed (step S4203). At this 
point, this ARP request may be transmitted in a form of the 
broadcast to the "local bus". 10 

The receiving terminal 4004 that received this ARP 
request enters the own 1394 address (EUI64 and "bus 
ID+physical ID") into this packet and returns this packet to 
the second 1394 bus 4013 as the ARP response (step S4204). 
At this point, the destination address of this ARP response is 
the 1394 address of the second half gateway 4003. 

The second half gateway 4003 which received this ARP 
response enters the own Ethernet address into a field for the 
resolved address, so as to carry out the deputy response with 
respect to the first half gateway 4002 (step S4205). At this 
point, the destination is the Ethernet address of the first half 20 
gateway 4002. Also, the second half gateway 4003 recog- 
nizes that a terminal having the IP address of the receiving 
terminal 4004 exists on the second 1394 bus 4013 side, and 
registers this fact into the internal routing table. 

The first half gateway 4002 that received this ARP 
response enters the own 1394 address into a field for the 
resolved address, and carries out the deputy response with 
respect to the transmitting terminal 4001 (step S4206). At 
this point, the destination is the 1394 address of the trans- 

. . 30 

mitting terminal 4001. Also, the first half gateway 4002 
recognizes that a terminal having the IP address of the 
receiving terminal 4004 exists on the Ethernet 4012 side, 
and registers this fact into the internal routing table. 

In this manner, the transmitting terminal 4001 can ascer- 35 
tain that it suffices to transmit the IP packets destined to the 
receiving terminal 4004 with respect to (the 1394 address of) 
the first half gateway 4002. 

Note that FIG. 37 shows a case of the address resolution 
in which the ARP request reaches to the target node once and 40 
then the ARP response is sequentially returned backwards 
from there, but it is not necessarily limited to this case, and 
it is also possible to use a case of the address resolution in 
which the intermediate node directly carries out the address 
resolution when the intermediate node already has an infor- 45 
mation on the target node. 

Now, the transmitting terminal 4001 already recognizes 
that it is the FANP node itself and that what is to be 
transmitted from now on with respect to the receiving 
terminal 4004 is the video. Consequently, the transmitting 50 
terminal 4001 intends that the video to be transmitted from 
now on will be forwarded by the datalink processing alone 
without using the IP processing at the intermediate FANP 
nodes. 

To this end, after the confirmation of the initial setting and 55 
the coding scheme using the IP packets and the confirmation 
of the video reception capability with respect to the receiv- 
ing terminal 4004, the transmitting terminal 4001 proceeds 
to the video transmission preparation. FIG. 38 shows the 
sequence for this operation. 60 

First, the transmitting terminal 4001 accesses the register 
of the isochronous resource manager on the first 1394 bus 
4011 to reserve the bandwidth necessary for the video 
transmission and acquire the isochronous channel number, 
between the transmitting terminal 4001 and the first half 65 
gateway 4002 (step S4401). FIG. 39 shows the isochronous 
channel 4301 obtained at this point. 
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Then, the transmitting terminal 4001 transmits the pro- 
pose message of the FANP with respect to the first half 
gateway 4002 through that isochronous channel 4301. This 
propose message is transmitted by entering the own ESI and 
sequence number as the VCID and the IP address (N. 4) of 
the receiving terminal 4004 as the target IP address (step 
S4402). 

The first half gateway 4002 that received this propose 
message recognizes that it is the FANP packet (propose 
message), confirms the final destination IP address (the 
receiving terminal 4004) from the target IP address, and 
confirms that this address exists on the Ethernet cable 4012 
side by referring to the internal routing table. Then, the first 
half gateway 4002 enters the own IP address into the 
propose ACK message and returns it to the asynchronous 
channel or asynchronous write of the first 1394 bus 4011 
(step 4403). 

The transmitting terminal 4001 that received this propose 
ACK message transmits the offer message to the asynchro- 
nous channel or asynchronous write of the first 1394 bus 
4011, by entering the IP address of the first half gateway 
4002 as the destination IP address, entering the VCID 
described above, entering the IP address of the receiving 
terminal 4004 which is the final destination into the flow ID 
similarly as in the first embodiment, and containing the 
necessary bandwidth value and the end-to-end ACK request 
(step S4404). At this point, the destination 1394 address is 
obviously the 1394 address of the first half gateway 4002. 

The first half gateway 4002 that received this offer mes- 
sage recognizes that it is the FANP packet, confirms the final 
destination IP address (the receiving terminal 4004) from the 
flow ID, and re-confirms that this address exists on the 
Ethernet cable 4012 side. 

Here, in order to make it possible for the second half 
gateway 4003 to transmit the data to be transmitted directly 
to the isochronous channel or the destination address with 
the specific register offset value on the 1394 bus 4013 by 
only confirming the Ethernet header value, a value different 
from the Ethernet address "A2" unique to the second half 
gateway 4003 is used as the destination address of the 
Ethernet frame to be transmitted. This value can be any 
value as long as it is different from values of the Ethernet 
addresses of the first half gateway 4002 and the second half 
gateway 4003, that is, the address not used on the Ethernet 
cable, and it is different from values currently used for the 
direct forwarding at the datalink layer for the other flows. 

For example, when the Ethernet address value selected by 
the first half gateway 4002 here is "#A", only the video 
information directed to the receiving terminal 4004 will be 
mounted on every subsequent Ethernet frame which has 
"#A" as the destination Ethernet address. This is equivalent 
to having the virtual connection with "#A" as VCI estab- 
lished between the first half gateway 4002 and the second 
half gateway 4003. This is shown in FIG. 39 as the con- 
nection 4302. 

Note that the half gateways 4002 and 4003 have the initial 
setting by which a frame destined to any Ethernet address 
will be handed to the IP/FANP processing unit 4105 once 
along with its destination Ethernet address value, except 
when it is a frame which passes through the 1394/Ethernet 
transfer unit 4106. By this setting, it becomes possible for 
the IP/FANP processing unit 4105 to make the setting 
according to the content of the FANP packet by which the 
switching at the datalink layer is carried out by making 
appropriate setting to the 1394/Ethernet transfer unit 4106, 
for the necessary Ethernet address. 
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The first half gateway 4002 transmits the propose mes- 
sage of the FANP through the connection 4302 of FIG. 39 
(step S4406). This propose message is transmitted by enter- 
ing the own ESI and sequence number as the VCID and the 
IP address (N. 4) of the receiving terminal 4004 as the target 5 
IP address. 

The second half gateway 4003 that received this propose 
message recognizes that it is the FANP packet (propose 
message), confirms the final destination IP address (the 
receiving terminal 4004) from the target IP address, and 10 
confirms that this address exists on the second 1394 bus 
4013 side by referring to the internal routing table. Then, the 
second half gateway 4003 returns the propose ACK message 
to the Ethernet cable 4012, by entering the own IP address 
as the target IP address and the Ethernet address of the first 15 
half gateway 4002 as the destination address (step S4407). 

As can be seen from this description, a case of transmis- 
sion using the usual Ethernet address as the destination 
header of the Ethernet frame corresponds to a case of 
transmission by the "default VC" in the FANP. 20 

The first half gateway 4002 that received this propose 
ACK message transmits the offer message onto the Ethernet 
cable 4012, by entering the IP address of the second half 
gateway 4003 as the destination IP address, entering the 25 
VCID described above, entering the IP address of the 
receiving terminal 4004 which is the final destination into 
the flow ID, and containing the necessary bandwidth value 
and the end-to-end ACK request (step S4408). At this point, 
the destination Ethernet address is the Ethernet address of 3Q 
the second half gateway 4003. 

The second half gateway 4003 that received this offer 
message recognizes that it is the FANP packet, confirms the 
final destination IP address (the receiving terminal 4004) 
from the flow ID, and re-confirms that this address exists on 35 
the second 1394 bus 4013 side. 

Then, the second half gateway 4003 reserves the band- 
width and the isochronous channel number or the destination 
address with the specific register offset by the setting in the 
register of the isochronous resource manager of the second 40 
1394 bus, in order to transmit the video signals by reserving 
the necessary bandwidth up to the receiving terminal 4004 
(step S4410). FIG. 39 shows the isochronous channel 4303 
obtained at this point. 

Then, the second half gateway 4003 transmits the propose 45 
message of the FANP through this isochronous channel 4303 
(step S4411). 

The receiving terminal 4004 that received this propose 
message transmits the propose ACK message to the second 
half gateway 4003 if it is acceptable (step S4412). 50 

Then, the second half gateway 4003 transmits the offer 
message of the FANP to the receiving terminal 4004 (step 
S4413). 

When the reception is possible, the receiving terminal 55 
4004 transmits the re-direct message to the upstream FANP 
node (the second half gateway 4003 in this case) by setting 
the end-to-end ACK flag ON (step S4414). This setting of 
the end-to-end ACk flag is the processing related to the fact 
that the end-to-end ACK request is contained in the offer 60 
message of the FANP transmitted to the receiving terminal 
4004 and that this terminal is the final terminal. 

The second half gateway 4003 that received this re-direct 
message judges that the preparation for the isochronous 
channel use on the downstream side (the receiving terminal 65 
4004 in this case) is ready, and makes the setting by which 
the direct datalink layer forwarding can be carried out for the 
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SDU (Service Data Unit) of the frame that arrives with the 
Ethernet address #A (4302) without using the processing by 
the IP/FANP processing unit 4105 at the 1394/Ethernet 
transfer unit 4106 inside the second half gateway 4003. By 
this setting, for a frame that arrives with the specific Ethernet 
address "#A", its SDU can be transmitted to the isochronous 
channel 4303 directly by referring to the correspondence 
table as shown in FIG. 36, so that the efficiency and the 
speed of the data forwarding processing can be improved 
considerably. 

Also, the above described processing does not use the 
processing at the IP/FANP processing unit 4105 so that the 
reduction of the load on the IP/FANP processing unit 4105 
and the load distribution can be realized simultaneously. In 
addition, it is also possible to transmit data which is not an 
IP packet. 

The second half gateway 4003 transmits the re-direct 
message to the upstream FANP node (the first half gateway 

4002 in this case) (step S4415). At this point, the end-to-end 
ACK flag is erected in the re-direct message from the 
downstream side so that the end-to-end ACK flag is set ON. 

In this manner, the re-direct message is delivered to the 
transmitting terminal 4001 through the second half gateway 

4003 and the first half gateway 4002. 

At the first half gateway 4002, the isochronous channel 
4301 and the direct conversion into the Ethernet frame 4302 
with the Ethernet address "#A" are set to the 1394/Ethernet 
transfer unit 4106. Also, at a time of forwarding the re-direct 
message, the re-direct message is delivered by using the 
asynchronous channel or asynchronous write of each 1394 
bus or the formal Ethernet address "Al" on the Ethernet. 

When the re-direct message with the end-to-end ACK flag 
erected is received at the transmitting terminal 4001 in this 
manner (step S4416), the transmitting terminal 4001 can 
confirm that the isochronous channel 4301 was directly 
connected at the datalink layer level up to the receiving 
terminal 4004. Then, the transmitting terminal 4001 starts 
the video data transmission through the isochronous channel 

4301 (step S4417). 

The video data can be transmitted through the connection 

4302 and the isochronous channel 4303 to the receiving 
terminal 4004 by the datalink layer processing alone, with- 
out using the processing by the IP/FANP processing unit 
4105 at the intermediate nodes of the half gateways 4002 
and 4003 

Note that the video information to be transmitted here 
may be the video data encapsulated within the IP packet 
similarly as in the first embodiment, or the video data 
directly mounted on the 1394 isochronous channel (or the 
Ethernet frame 4302 with the destination Ethernet address 
"#A"). Also, the video information may be transmitted in a 
form of the 1394 frame directly mounted on the Ethernet 
frame. 

When the maintaining of the connection is realized by 
maintaining the soft state similarly as in the first 
embodiment, the above described re-direct message is regu- 
larly transmitted to the upstream direction. When this 
re-direct message does not arrive for a certain period of time 
or when an explicit message for disconnecting the connec- 
tion (the release message) comes from the upstream 
direction, this soft state is released and the setting of the 
1394/Ethernet transfer unit 4106 regarding that direct 
datalink layer connection is also cleared. 

As described, by using a plurality of half gateways (4002, 
4003) and the Ethernet cable (4012) that connects them, it 
becomes possible to carry out the communication by inter- 
connecting a plurality of 1394 buses by the half gateways. 



US 6,751 

49 

FIG. 40 shows an exemplary style of using the half 
gateways and the Ethernet cable. As shown in FIG. 40, a 
1394 inter-connection cable has a physical shape in which a 
long Ethernet cable 4503 is connected between two half 
gateways 4002 and 4003 in advance. This cable portion may 5 
be connected by an electric cable such as UTP5 or coaxial 
cable, or by an optical cable such as a plastic optical fiber. 
It should be noted however that the transmission scheme of 
the physical layer is supposed to obey the Ethernet standard. 

Also, to the respective half gateways, the 1394 connectors 1° 
4501 and 4502 are connected through relatively short cables 
(dedicated 1394 cables). Here, the dedicated 1394 cables are 
connected so that the power supply to the half gateways 
4002 and 4003 can be made through the respective 1394 
connectors 4501 and 4502 and this 1394 cable. 15 
Consequently, the system of FIG. 40 requires no special 
power supply. From a viewpoint of a user who wishes to 
inter-connect two 1394 buses, this implies that the connec- 
tion is basically completed by simply connecting one end 
(4501) of the cable to the first 1394 bus 4011 and the other 20 
end (4502) of the cable to the second 1394 bus 4013, so that 
the convenience regarding the connecting operation can be 
improved remarkably. 

Also, the 1394 cable basically has an upper limit of 4.5 m 
in length, but according to the present invention, a long cable 25 
(such as that of several hundred meters, for example) can be 
used as a cable for connecting the half gateways 4002 and 
4003, so that it is very useful in a case of connecting the 
1394 buses which are far apart from each other. 

30 

In the above, an example using a long cable has been 
described, but as shown in FIG. 41, it is also possible to 
connect the half gateways 4002 and 4003 by radio. In FIG. 
41, 4801 and 4802 are 1394 connectors while 4803 and 4804 
are radio transceiver devices used for the inter-connection 
by radio. 

In a case of using the MAC frame as the radio transmis- 
sion scheme, the scheme of this second embodiment is 
basically applicable directly. When the radio interface is 
provided between the half gateways in this manner, this 4Q 
connection becomes wireless so that a user can arrange the 
wiring easily. 

Note that the 1394 inter-connection cable is not only 
applicable to a case of forming the connection between the 
1394 half gateways as described above and shown in FIG. 45 
40 and FIG. 41, but also to a case of realizing the usual 1394 
bridge in the half bridge configuration. In that case, the 
function of the 1394 bridge can be realized by changing 
those portions of the above description which are described 
as "specifying the destination IP address" to the processing 50 
of the 1394 address. 

Note also that, as shown in FIG. 42, at the transmitting 
terminal, the MPEG video from the digital satellite broad- 
cast (or the digital CATV) can be received and this MPEG 
video can be re-formatted into the MPEG-over -1394 format 55 
or converted into the raw video data by the MPEG decoder 
and then transmitted as the data on the isochronous channel 
of the 1394. 

When this implementation is used, even for the video data 
(or speech data, usual data, etc.) which is not accommodated 60 
originally by the transfer packets used at the home such as 
those of the network layer like the IP packets, the datalink 
layer frames like those of the IEEE 1394, etc., the data 
transfer in the home network becomes possible so that it 
becomes possible to realize the data distribution to the home 65 
network without requiring the cable wiring change for the 
purpose of the video broadcasting. 
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FIG. 43 shows an exemplary internal configuration of the 
transmitting terminal 4901 for realizing this implementation. 
In FIG. 43, the transmitting terminal 4901 comprises a 
satellite broadcast receiving interface unit 9001, an MPEG 
data format conversion unit 9002, an IP/FANP processing 
unit 9003, a MUX/DEMUX 9004, and a 1394 interface unit 
9005. 

The satellite broadcast receiving interface unit 9001 is an 
interface for receiving data from the satellite broadcast, 
which transmits the data after the data formatting to the 
MPEG data format conversion unit 9002. 

The MPEG data format conversion unit 9002 converts the 
transmitted MPEG data from the MPEG data format suitable 
for the satellite broadcast to the MPEG data format on the 
IEEE 1394, i.e., the MPEG-over-1394, and transmits it to 
the MUX/DEMUX 9004. Here, the de-scrambling 
processing, etc. may also be carried out in addition. 

The IP/FANP processing unit 9003 and the 1394 interface 
processing unit 9005 have the similar functions as those 
described above so that their description will be omitted 
here. 

At the MPEG data format conversion unit 9002, the 
appropriate format conversion is applied to the transmitted 
MPEG data so that the MPEG data from the satellite 
broadcast can be transmitted to the video terminal through 
the 1394. 

FIG. 44 shows an exemplary internal configuration of the 
transmitting terminal 4901 in a case of decoding the MPEG 
data received from the satellite broadcast at the transmitting 
terminal 4901, and forwarding the raw video data to the 
video terminal through the 1394 bus. 

FIG. 44 differs from FIG. 43 in that the MPEG decoding 
is carried out at the MPEG decoding unit 9102 so that the 
raw video data is transmitted to the 1394 bus. 

When the MPEG decoding unit 9102 or the MPEG data 
format conversion unit 9002 is equipped with a function for 
processing several channels simultaneously, it becomes pos- 
sible to realize the distribution of the video information in 
several channels simultaneously to the home network, so 
that it is very useful in a case where it is desirable to watch 
a plurality of video programs as in a case where a plurality 
of family members watch the television simultaneously. 

Note here that the MPEG decoding unit 9102 and the 
MPEG data format conversion unit 9002 may or may not 
carry out the encapsulation of the video data within the IP 
packet. 

It is to be noted that the "transmitting terminal" in the 
above description can be provided in a form of what is 
generally known as "set-top box". 

It is also to be noted that this second embodiment has been 
described for an exemplary case of using the IEEE 1394 bus, 
but this second embodiment is also applicable to the other 
datalink layer technology such as the ATM, for example. In 
such a case, it suffices to use the VPI/VCI value instead of 
the channel number. 

Third Embodiment 

Next, with references to FIG. 45 to FIG. 50, the third 
embodiment of the present invention will be described in 
detail. 

This third embodiment is directed to a communication 
network system formed by two or more 1394 buses, that is 
a communication network system formed by nodes called 
half gateways which are connected to the respective 1394 
buses, and a network for connecting these half gateways. 
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Here, an exemplary case of using the Ethernet as a network 
for connecting the half gateways, and providing an Ethernet 
switch having a plurality of FANP functions between the 
half gateways will be described. 

FIG. 45 shows an exemplary overall configuration of a 5 
communication network system (a home network system for 
connecting various electric devices inside the home, for 
example) according to this third embodiment. As shown in 
FIG. 45, this communication network system comprises a 
transmitting terminal 5001, a first half gateway 5002, a 1° 
FANP Ethernet switch 5003, a second half gateway 5004, a 
receiving terminal 5005, a first 1394 bus 5011, a first 
Ethernet cable 5012, a second Ethernet cable 5013, and a 
second 1394 bus 5014. 

Here, it is assumed that the entire system constitutes a 15 
home network within the same home, similarly as in the first 
embodiment. Consequently, among the devices contained in 
this system, those which are the IP nodes are assumed to be 
belonging to the same IP subnet. Here, this IP subnet is 
assumed to have an IP subnet address N, and the IP 20 
addresses of the nodes are assumed to be N. 1 for the 
transmitting terminal 5001, N. 2 for the first half gateway 
5002, N. 3 for the FANP Ethernet switch 5003, N. 4 for the 
second half gateway 5004, and N. 5 for the receiving 
terminal 5005. 25 

Also, the 1394 addresses and the Ethernet addresses of 
these nodes are as shown in FIG. 45. 

Each of the transmitting terminal 5001, the first half 
gateway 5002, the FANP Ethernet switch 5003, the second ^ 
half gateway 5004 and the receiving terminal 5005 of this 
embodiment is the FANP node as described in the first 
embodiment which has the extended FANP function of the 
present invention. 

Here, the transmitting terminal 5001, the first half gate- 35 
way 5002, the second half gateway 5004 and the receiving 
terminal 5005 have the same functions as the corresponding 
elements in the second embodiment described above so that 
their detailed description will be omitted here. 

In this embodiment, the first half gateway 5002 and the 40 
second half gateway 5004 are connected by the Ethernet 
cables 5012 and 5013. Namely, in this embodiment, the data 
exchanges between two half gateways are to be carried out 
in terms of the Ethernet frames. 

The FANP Ethernet switch 5003 is an Ethernet switch 45 
having the FANP functions, and as will be described below, 
it has a function for taking the entered FANP packet into the 
internal IP/FANP processing unit (which is realized by 
looking at the protocol type of the Ethernet frame), and a 
function for rewriting the Ethernet address of a frame before 50 
and after the input/output of the frame, as set up in the 
internal table in advance, and outputting this frame. The 
latter function is provided for carrying out the similar 
operation as the rewriting of the VPI/VCI at the ATM switch 
node before and after the input/output of an ATM cell. 55 

In this embodiment, the FANP Ethernet switch 5003 (or 
the internal switch) is in a two-port physical configuration, 
but it is also possible to construct a multi-port FANP 
Ethernet switch by the similar construction method and 
mechanism. 60 

FIG. 46 shows an exemplary internal configuration of the 
FANP Ethernet switch 5003. As shown in FIG. 46, the FANP 
Ethernet switch 5003 comprises a first Ethernet interface 
unit 5101, a first MUX/DEMUX 5102, an IP/FANP pro- 
cessing unit 5103, an Ethernet frame switching and Ethernet 65 
header rewriting unit 5104, a second MUX/DEMUX 5105, 
and a second Ethernet interface unit 5106. 



The Ethernet interface units 5101 and 5106 are interfaces 
with respect to the physically connected Ethernets, and 
carries out the encapsulation and decapsulation of data to be 
exchanged with the MUX/DEMUXs 5102 and 5105 and the 
Ethernet frames. 

The IP/FANP processing unit 5103 has functions for 
carrying out the routing based on the IP address, the routing 
table management, the FANP processing, the ARP 
processing, etc., for the received IP packets, FANP packets, 
ARP packets, etc., as well as a function for making appro- 
priate setting to the Ethernet frame switching and Ethernet 
header rewriting unit 5104. 

The Ethernet frame switching and Ethernet header rewrit- 
ing unit 5104 has a function for switching an Ethernet frame 
received from either interface to an appropriate output port 
by referring to its destination Ethernet address, and a func- 
tion for rewriting at least a part of the Ethernet address at a 
time of the above switching according to the setting from the 
IP/FANP processing unit 5103. To this end, the Ethernet 
frame switching and Ethernet header rewriting unit 5104 
may have a header conversion table provided therein simi- 
larly as in the ATM switch. The Ethernet frame switching 
and Ethernet header rewriting unit 5104 also has a function 
for learning the Ethernet address, which functions to refer to 
a source address of an entered Ethernet frame and store it 
along with an input port for a certain period of time. 

Note that the Ethernet frame that passes through this 
Ethernet frame switching and Ethernet header rewriting unit 
5104 can pass without being applied with the processing by 
the IP/FANP processing unit 5103. 

Next, for an exemplary case of transmitting video from 
the transmitting terminal 5001 to the receiving terminal 
5005, the operation sequence in time order will be described 
with references to FIG. 47 and FIG. 48. 

FIG. 47 shows a sequence for the ARP (Address Reso- 
lution Protocol). 

First, the transmitting terminal 5001 transmits the ARP 
request packet to the first 1394 bus 5011 in order to carry out 
the address resolution for ascertaining the datalink layer 
address of the receiving terminal 5005 from its IP address 
(step S5401). As described in the second embodiment, this 
ARP request is broadcasted on the local bus (that is, the first 
1394 bus 5011). 

The first half gateway 5002 which is the FANP node that 
received this ARP request operates similarly as in the second 
embodiment. As a result, this ARP request is forwarded to 
the Ethernet cable 5012 by setting the Ethernet broadcast 
address as the destination address (step S5402). 

The FANP Ethernet switch 5003 also receives this ARP 
request, but as it does not have the corresponding IP address, 
the ARP response will not be sent from there. 

Also, this ARP request is forwarded to the second Ether- 
net cable 5013 through the Ethernet frame switching and 
Ethernet header rewriting unit 5104. Note that, in this case 
(a case where the destination address is the broadcast 
address), the rewriting of the Ethernet address is not carried 
out so that the ARP request is forwarded as it is. 

The second half gateway 5004 and the receiving terminal 
5005 that received this ARP request also operate similarly as 
in the second embodiment (step S5403). Namely, the receiv- 
ing terminal 5005 that received this ARP request enters the 
own 1394 address (EUI64 and "bus ID+physical ID") into 
this packet and returns this packet to the second 1394 bus 
5014 as the ARP response (step S5404), and this ARP 
response reaches to the FANP Ethernet switch 5003. At this 
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point, the destination address of the Ethernet frame is the 
Ethernet address "Al" of the first half gateway 5002. 

As described above, the FANP Ethernet switch 5003 has 
the learning function, and holds the Ethernet address of the 
first half gateway 5002 and its physical port direction (that 
is, the first Ethernet cable 5012 side) as a table at a time of 
the ARP request, so that this ARP response is switched by 
the Ethernet frame switching and Ethernet header rewriting 
unit 5104 and reaches to the first half gateway 5002 (step 
S5405). 

Then, as the first half gateway 5002 returns the ARP 
response (deputy response) (step S5406), this ARP response 
eventually reaches to the transmitting terminal 5001. 

In this manner, the transmitting terminal 5001 can ascer- 
tain that it suffices to transmit the IP packets destined to the 
receiving terminal 5005 with respect to (the 1394 address of) 
the first half gateway 5002. 

Next, similarly as in the second embodiment, the trans- 
mitting terminal 5001 intends that the video to be transmit- 
ted from now on will be forwarded by the datalink process- 
ing alone without using the IP processing at the intermediate 
FANP nodes, and after the confirmation of the initial setting 
and the coding scheme using the IP packets and the confir- 
mation of the video reception capability with respect to the 
receiving terminal 5005, the transmitting terminal 5001 
proceeds to the video transmission preparation. FIG. 48 
shows the sequence for this operation which will now be 
described. 

Among the operations of the transmitting terminal 5001 
and the first half gateway 5002, the operations for the 
exchanges of the messages between them (up to the trans- 
mission of the pending message of the FANP) are the same 
as in the second embodiment (step S5501 to step S5505). 

The first half gateway 5002 that received the offer mes- 
sage from the transmitting terminal 5001 recognizes that it 
is the FANP packet, confirms the final destination IP address 
(the receiving terminal 5005) from the flow ID, and confirms 
that this address exists on the Ethernet cable 5012 side. Here, 
in order to make it possible for the next hop FANP node to 
carry out the direct datalink layer switching of the data to be 
transmitted by only confirming the Ethernet header, a value 
different from the Ethernet address unique to the second half 
gateway 5004 is used as the destination address of the 
Ethernet frame to be transmitted. This value can be any 
value as long as it is different from values of the Ethernet 
addresses of the first half gateway 5002 and the second half 
gateway 5004. 

For example, when the Ethernet address value selected by 
the first half gateway 5002 here is "#A", only the video 
information directed to the receiving terminal 5005 will be 
mounted on every subsequent Ethernet frame which has 
"#A" as the destination Ethernet address. This is equivalent 
to having the virtual connection with "#A" as VCI estab- 
lished between the first half gateway 5002 and the next hop 
FANP node (more specifically, the FANP Ethernet switch 
5003). This is shown in FIG. 49 as the connection 5302. 

The first half gateway 5002 transmits the propose mes- 
sage of the FANP through this connection 5302 (step 
S5506). At this point, a number indicating the FANP is to be 
entered into the protocol type of the Ethernet frame. Also, 
this propose message is transmitted by entering the own ESI 
and sequence number as the VCID and the IP address of the 
receiving terminal 5005 as the target IP address. 

The FANP Ethernet switch 5003 that received this pro- 
pose message recognizes that it is the FANP packet (propose 
message) by referring to the protocol type field of the 
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Ethernet frame, and transfers it to the internal IP/FANP 
processing unit 5103. Then, the FANP Ethernet switch 5003 
confirms that the destination Ethernet address of this Eth- 
ernet frame exists on the second half gateway 5004 side, and 

5 registers this in relation to the final destination IP address 
(the receiving terminal 5005) in the internal routing table. 
Then, the FANP Ethernet switch 5003 returns the propose 
ACK message to the first Ethernet cable 5012, by entering 
the own IP address as the target IP address and the Ethernet 

10 address of the first half gateway 5002 as the destination 
address (step S5507). 

The first half gateway 5002 that received this propose 
ACK message transmits the offer message onto the first 
Ethernet cable 5012, by entering the IP address "N. 3" of the 

15 FANP Ethernet switch 5003 as the destination IP address, 
entering the VCID described above, entering the IP address 
"N. 5" of the receiving terminal 5005 which is the final 
destination into the flow ID, and containing the necessary 
bandwidth value and the end-to-end ACK request (step 

20 S5508). At this point, the destination Ethernet address is the 
Ethernet address "A2" of the FANP Ethernet switch 5003. In 
this case, a number indicating the FANP may also be entered 
into the protocol type of the Ethernet frame. 

The FANP Ethernet switch 5003 that received this offer 

25 message recognizes that it is the FANP packet, and transfers 
it to the IP/FANP processing unit 5103. Here, the FANP 
Ethernet switch 5003 also confirms the final destination IP 
address (the receiving terminal 5005) from the flow ID, and 
confirms that this address exists on the second Ethernet 

30 cable 5013 side. Here, also, in order to make it possible for 
the next hop FANP node (more specifically, the second half 
gateway 5004) to carry out the direct datalink layer switch- 
ing of the data to be transmitted by only confirming the 
Ethernet header, a value different from the Ethernet address 

35 

unique to the second half gateway 5004 is used as the 
destination address of the Ethernet frame to be transmitted. 

For example, when the Ethernet address value selected by 
the FANP Ethernet switch 5003 is "#B", it is equivalent to 

4Q having the virtual connection with "#B" as VCI established 
between the FANP Ethernet switch 5003 and the second half 
gateway 5004 which is the next hop FANP node. This is 
shown in FIG. 49 as the connection 5303. 

The FANP Ethernet switch 5003 transmits the propose 

45 message of the FANP through this connection 5303 (step 
S5510). Thereafter, the procedure is the same as in the 
second embodiment. 

The FANP Ethernet switch 5003 that received the 
re-direct message from the downstream side (step S5519) 

50 judges that the preparation for the dedicated virtual channel 
use on the downstream side (the second half gateway 5004 
in this case) is ready, and makes the setting by which the 
direct datalink layer forwarding (Ethernet switching) can be 
carried out for the Ethernet frame that arrives with the 

55 Ethernet address #A from the first Ethernet cable 5012 side 
without using the processing by the IP/FANP processing unit 
5103 at the Ethernet frame switching and Ethernet header 
rewriting unit 5104 inside the FANP Ethernet switch 5003. 
At this point, the setting is also made in the internal Ethernet 

60 header conversion table so that the destination Ethernet 
address will be converted from "#A" to "#B" and this 
Ethernet frame will be switched to an appropriate output 
port (the second Ethernet cable 5013 in this embodiment). 
By this setting, a frame that subsequently arrives with the 

65 specific Ethernet address "#A" from the first Ethernet cable 
5012 can be transmitted to the second Ethernet cable 5013 
by the direct Ethernet switching upon converting the desti- 
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nation Ethernet address to "#B" and after the Ethernet 
header conversion is carried out, so that the efficiency and 
the speed of the data forwarding processing can be improved 
considerably. 

Also, the above described processing does not use the 5 
processing at the IP/FANP processing unit 5103 so that the 
reduction of the load on the IP/FANP processing unit 5103 
and the load distribution can be realized simultaneously. 

In addition, it becomes possible to introduce a concept 
similar to the virtual connection into the Ethernets 5012 and 10 
5013, so as to enable the above described data forwarding. 

In this manner, the FANP Ethernet switch 5003 transmits 
the re-direct message to the upstream FANP node (the first 
half gateway 5002 in this case) (step S5520). At this point, 
the end-to-end ACK flag is erected in the re-direct message 15 
from the downstream side so that the end-to-end ACK flag 
is set ON. 

In the subsequent operations, the re-direct message with 
the end-to-end ACK flag erected is sent to the transmitting 
terminal 5001 similarly as in the second embodiment (step 20 
S5521). 

The transmitting terminal 5001 can confirm that the 
isochronous channel 5301 was directly connected at the 
datalink layer level up to the receiving terminal 5005. Then, 
the transmitting terminal 5001 starts the video data trans- 
mission through the isochronous channel 5301 (step S5522). 

The video data can be transmitted through 5302, 5303 and 
5304 to the receiving terminal 5005 by the datalink layer 
processing alone, without using the processing by the 3Q 
IP/FANP processing unit at the intermediate nodes including 
the half gateways 5002 and 5004 and the FANP Ethernet 
switch 5003, so that the guaranteed real-time video infor- 
mation transfer becomes easier. 

Note that, similarly as in the second embodiment, the 35 
video information to be transmitted here may be the video 
data encapsulated within the IP packet or the video data 
directly mounted on the 1394 isochronous channel (or the 
Ethernet frame with the destination Ethernet address given 
by "#A" or "#B"). Also, the Ethernet frame may be in a form 40 
in which the 1394 isochronous channel frame is mounted 
directly (or after appropriate processing is applied). 

Also, the re-direct message can be used for the purpose of 
maintaining the soft state similarly as in the second embodi- 
ment. 45 

As described, in this third embodiment, by using a plu- 
rality of half gateways (5002, 5004) and the Ethernet cables 
(5012, 5013) and the FANP Ethernet switch 5003 that 
connect them, it also becomes possible to carry out the 
communication by inter-connecting a plurality of 1394 50 
buses. In addition, it is also possible to connect three or more 
half gateways to the FANP Ethernet switch 5003, for 
example. 

FIG. 50 shows another exemplary style of using the half 
gateways and the Ethernet cables. A 1394 inter-connection 55 
cable shown in FIG. 50 has a physical shape in which a 1394 
connector 5501 is connected to a half gateway 5503 by being 
connected through a relatively short dedicated 1394 cable 
5502. Also, a long Ethernet cable 5504 is connected from the 
half gateway 5503 in advance. This cable portion may be 60 
connected by an electric cable such as UTP5 or coaxial 
cable, or by an optical cable such as a plastic optical fiber. 
It should be noted however that the transmission scheme of 
the physical layer is supposed to obey the Ethernet standard. 
A connector 5505 at a free end of the long Ethernet cable 65 
5504 is a connector in compliance with that physical layer 
transmission scheme. 
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This 1394 inter-connection cable is used by connecting 
the 1394 connector 5501 to a desired 1394 bus to be 
connected, and connecting the FANP Ethernet switch 5003 
at the connector 5505 side. The FANP Ethernet switch 5003 
may have a plurality of connector insertion ports. 

As described above, the 1394 connector 5501 is con- 
nected to the half gateway 5503 through the relatively short 
dedicated 1394 cable 5502, so that the power supply to the 
half gateway 5503 can be made through the 1394 connector 
5501 and the 1394 cable 5502. Consequently, the system of 
FIG. 50 requires no special power supply (although the 
power supply to the FANP Ethernet switch 5003 is basically 
necessary). From a viewpoint of a user who wishes to 
inter-connect two 1394 buses, this implies that the connec- 
tion is basically completed by simply connecting one end 
(5501) of the cable to a desired 1394 bus to be connected and 
the other end (5505) of the cable to the FANP Ethernet 
switch 5003, so that the convenience regarding the connect- 
ing operation can be improved remarkably. 

Also, a long cable (such as that of several hundred meters, 
for example) can be used as a cable for connecting the half 
gateway 5503 and the FANP Ethernet switch 5003, so that 
it is very useful in a case of connecting the 1394 buses which 
are far apart from each other. 

It should be apparent that the above described 1394 
inter-connection cable is not only applicable to a case of 
forming the connection between the 1394 half gateways as 
described above, but also to a case of realizing the usual 
1394 bridge in the half bridge configuration. In that case, the 
function of the 1394 bridge can be realized by using the 
1394 address instead of the IP address, similarly as in the 
second embodiment. 

It is also to be noted that, in the second and third 
embodiments, the transmission scheme between the half 
gateways using the Ethernet has been described, but it is also 
possible to realize a case of using the other network such as 
token ring, FDDI, etc., without changing the above 
described mechanism. 

Fourth Embodiment 

The second and third embodiments are directed to a case 
of the transmission scheme using the Ethernet, in which the 
datalink layer forwarding to the next hop FANP node (that 
is, the data forwarding/data switching to the next hop node 
by referring only to the datalink layer header) is carried out 
by using the destination Ethernet address as a virtual con- 
nection ID on this Ethernet. 

It is also possible to use the similar scheme in a case of 
using the ATM as the data transmission scheme between the 
half gateways. Here, however, unlike the case of using the 
Ethernet as the transmission scheme in which the destination 
Ethernet address is used as a virtual connection ID, the 
VPI/VCI of the ATM is to be used as a virtual connection ID. 

FIG. 51 shows a case of connecting the half gateways by 
the ATM transmission scheme in the home network system 
similar to that of the second embodiment shown in FIG. 33. 
Also, FIG. 52 shows an exemplary internal configuration of 
each of the half gateways 6002 and 6003 in FIG. 51. 

FIG. 51 and FIG. 52 differ from those of the second 
embodiment in that the connection between the half gate- 
ways 6002 and 6003 is realized by the ATM transmission 
scheme so that VPI/VCI value is used as the virtual con- 
nection ID, that an originally defined VPI/VCI value rec- 
ognized by both of the half gateways is reserved as the 
default VC (the meaning of which is the same as in the first 
embodiment), and that there is no limit on a length of the 
ATM cable. 
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FIG. 53 shows a case of connecting the half gateways by 
the ATM transmission scheme in the home network system 
similar to that of the third embodiment shown in FIG. 45. 
FIG. 53 differs from FIG. 45 in that a FANP ATM switch 
6203 is provided instead of the FANP Ethernet switch 5003. 5 
Also, FIG. 54 shows an exemplary internal configuration of 
the FANP ATM switch 6203 in FIG. 53. 

FIG. 53 and FIG. 54 differ from those of the third 
embodiment in that the connection between the half gate- 
ways 6202 and 6203 is realized by the ATM transmission 1Q 
scheme so that VPI/VCI value is used as the virtual con- 
nection ID, that an originally defined VPI/VCI value rec- 
ognized by both of the half gateways is reserved as the 
default VC (the meaning of which is the same as in the first 
embodiment), and that there is no limit on a length of the 15 
ATM cable. In addition, an architecture of the FANP ATM 
switch 6203 is new. 

Here, the default VC is terminated at the IP/FANP pro- 
cessing unit 6302 (see FIG. 54), and cells will pass through 
an ATM switch 6303 before they reaches to the IP/FANP 20 
processing unit 6302. 

Consequently, in order to establish a direct datalink layer 
connection, that is an ATM connection, between ATM 
interface units 6301 and 6304, the IP/FANP processing unit 
6302 is required to have a function for making an appro- 25 
priate setting for values of the header conversion table inside 
the ATM switch 6303, and a function for directly connecting 
a specific ATM-VC of an ATM cable 6212 and a specific 
ATM-VC of an ATM cable 6213 at the ATM layer. 

Note also that the realization of the connection between 30 
the half gateways according to the present invention encom- 
passes not only the transmission schemes such as the Eth- 
ernet and ATM, but also the general connection-less and 
connection-oriented transmission schemes as well. 

35 

Fifth Embodiment 

Next, with references to FIG. 55 to FIG. 57, the fifth 
embodiment of the present invention will be described in 
detail. 

This fifth embodiment is directed to a case of applying the 40 
scheme of the present invention as described above to the 
route setting and the bandwidth reservation using the MAC 
address. 

FIG. 55 shows an exemplary overall configuration of a 
communication network system according to this fifth 45 
embodiment. As shown in FIG. 55, this communication 
network system comprises a transmitting terminal 8001, a 
first gateway 8002, a second gateway 8003, a third gateway 
8004, a receiving terminal 8005, an ATM network 8011, a 
first Ethernet 8012, a second Ethernet 8013, and a 1394 bus 50 
8014. 

Here, it is assumed that the entire system constitutes a 
home network within the same home, similarly as in the first 
embodiment. Consequently, among the devices contained in 
this system, those which are the IP nodes are assumed to be 55 
belonging to the same IP subnet. Here, this IP subnet is 
assumed to have an IP subnet address N. However, unlike 
the second embodiment, two gateways (the second gateway 
8003 and the third gateway 8004) for connecting the first 
Ethernet, the second Ethernet and the 1394 bus are bridges, 60 
so that they may not necessarily have IP addresses (and they 
may not necessarily have IP processing units). The IP 
addresses of the nodes are assumed to be N. 1 for the 
transmitting terminal 8001, N. 2 for the first gateway 8002, 
and N. 3 for the receiving terminal 8005. Also, the 1394 65 
addresses and the Ethernet addresses of these nodes are as 
shown in FIG. 55. 
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Here, the nodes (the third gateway 8004 and the receiving 
terminal 8005) connected with the 1394 bus 8014 are also 
allocated with the MAC addresses. This can happen in 
several cases including the following. 

(1) A case in which the 1394 bus 8014 is emulating the 
IEEE 802 type network such as the Ethernet. 

(2) A case in which the MAC address is expressed by 
using a part of a region for the 1394 address. 

Namely, this embodiment uses the expression scheme in 
which "a value of EUI64 is expressed by the MAC address", 
for example. As such, it suffices to have a situation in which 
a node on the 1394 bus 8014 can be uniquely identified by 
using the MAC address. 

Each of the transmitting terminal 8001, the first gateway 
8002, the second gateway 8003, the third gateway 8004 and 
the receiving terminal 8005 of this embodiment is the FANP 
node which has the extended FANP function of the present 
invention, but it differs from the FANP node of the first 
embodiment in that it is also capable of carrying out the 
route setting and the bandwidth (communication resource) 
reservation by using the MAC address rather than the IP 
address. This feature will now be described in detail. 

The transmitting terminal 8001 has the same functions as 
the transmitting terminal 4001 of the second embodiment 
except that it is connected to the ATM network, so that its 
detailed description will be omitted here. 

The first gateway 8002 is a FANP node for interconnect- 
ing the ATM network 8011 and the first Ethernet 8012, 
which has the same functions as the half gateway (4002, 
4003) of the second embodiment except that it transmits or 
receives FANP control messages in terms of the MAC 
addresses with respect to the direction of the first Ethernet 
8012. 

The second gateway 8003 inter-connects the Ethernets 
while the third gateway 8004 inter-connects the Ethernet and 
the 1394 bus, and they crucially differ from the first gateway 
8002 in that they are capable of carrying out the route setting 
and the bandwidth reservation by the MAC addresses rather 
than the IP addresses. Namely, the second gateway 8003 and 
the third gateway 8004 are MAC address compatible FANP 
relay nodes. 

Each of the second gateway 8003 and the third gateway 
8004 is a learning bridge having a function for learning the 
MAC address, which functions to refer to an input address 
of an entered frame (Ethernet frame, 1394 asynchronous 
frame), and store it along an input port for a certain period 
of time. 

The receiving terminal 8005 is the IP terminal as well, and 
has functions for exchanging IP packets with the transmit- 
ting terminal 8001, and receiving video delivered from the 
transmitting terminal 8001. It differs from the receiving 
terminal 4004 of the second embodiment in that this termi- 
nal also has a function for terminating the MAC address 
compatible FANP. 

FIG. 56 shows an exemplary internal configuration of the 
third gateway 8004. As shown in FIG. 56, the third gateway 
8004 comprises an Ethernet interface unit 8101, a first 
MUX/DEMUX 8102, an Ethernet/1394 transfer unit 8103, a 
FANP processing unit 8104, a second MUX/DEMUX 8105, 
and an 1394 interface unit 8106. 

The Ethernet interface unit 8101 is an interface with 
respect to the physically connected Ethernet, and carries out 
the encapsulation and decapsulation of data to be exchanged 
with the first MUX/DEMUX 8102 and the Ethernet frames. 

The first MUX/DEMUX 8102 has a function for referring 
to the protocol type field of the received Ethernet frame and 
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transferring this frame to the FANP processing unit 8104 if 
it is described as the FANP frame in the protocol type field, 
or to the Ethernet/1394 transfer unit 8103 otherwise. 

The FANP processing unit 8014 has functions for carrying 
out the routing based on the MAC address, the FANP 5 
processing, etc., for the received FANP packets, by referring 
to a table of correspondence between the MAC address and 
the output port provided inside the Ethernet/1394 transfer 
unit 8103. 

The Ethernet/1394 transfer unit 8104 has a function for 10 
attaching a specific Ethernet header to data received from 
the 1394 side, especially data received through the isochro- 
nous channel, by using its isochronous channel number or 
the destination address with the specific register offset as a 
key, and transmitting it to the Ethernet side, and a function 15 
for transmitting data received from the Ethernet side to a 
specific isochronous channel or the destination address with 
the specific register offset on the 1394 side by using its 
header information as a key, as well as a function of the 
learning bridge for forwarding frames according to the 20 
destination addresses (MAC addresses) of the frames while 
constantly updating the internal table of correspondence 
between the MAC address and the output port. Namely, the 
data forwarding by this Ethernet/1394 transfer unit 8104 is 
carried out by the datalink layer processing alone. Also, the 25 
correspondence table formed here becomes identical to that 
of FIG. 35 or FIG. 36. 

The 1394 interface unit 8106 carries out the physical layer 
processing, the link layer processing, the bus management, 
and the transaction layer processing of the 1394 with respect 30 
to the connected 1394 bus, and the exchanges of data (PDU 
from a viewpoint of the 1394) with the FANP processing 
unit 8104 or the Ethernet/1394 transfer unit 8103 by passing 
the 1394 frames to be transmitted or received through the 
second MUX/DEMUX 8105. 35 

Note that the second MUX/DEMUX 8105 has a function 
for transferring the 1394 frame received from the 1394 
interface unit 8106 to the FANP processing unit 8104 if an 
information indicating that it is the FANP frame is described 

40 

in that 1394 frame. 

Next, a case of transmitting video from the transmitting 
terminal 8001 to the receiving terminal 8005 will be 
described with reference to FIG. 57. 

First, the transmitting terminal 8001 transmits the ARP 45 
request packet to the ATM network 8011 in order to carry out 
the address resolution for ascertaining the datalink layer 
address of the receiving terminal 8005 from its IP address 
(step S5701). This ARP request is processed as the ATM- 
ARP within the ATM network 8011. 50 

This ARP request is forwarded to the first Ethernet 8012 
by the first gateway 8002. The first Ethernet 8012, the 
second Ethernet 8013 and the 1394 bus 8014 are bridge 
connected so that this ARP request is broadcasted within 
these bridge connected networks and directly reaches to the 55 
receiving terminal 8005 (step S5702). 

The receiving terminal 8005 makes the ARP response 
directly to the first gateway 8002, and the first gateway 8002 
makes the deputy ARP response to the transmitting terminal 
8001. At this point, the first gateway 8002 stores that the 60 
receiving terminal 8005 exists on the first Ethernet 8012 side 
(step S5703 and step S5704). 

Now, the transmitting terminal 8001 already recognizes 
that it is the FANP node itself and that what is to be 
transmitted from now on with respect to the receiving 65 
terminal 8005 is the video. Consequently, the transmitting 
terminal 8001 intends that the video to be transmitted from 
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now on will be forwarded by the datalink processing alone 
without using the IP processing at the intermediate FANP 
nodes. 

To this end, after the confirmation of the initial setting and 
the coding scheme using the IP packets and the confirmation 
of the video reception capability with respect to the receiv- 
ing terminal 8005, the transmitting terminal 8001 proceeds 
to the video transmission preparation. 

First, the transmitting terminal 8001 carries out the ATM 
signaling so as to acquire an appropriate VC (step S5705). 
Then, the transmitting terminal 8001 carries out the FANP 
exchanges with respect to the first gateway 8002 through 
that VC. Here, the exchanges to be carried out are the same 
as in the first embodiment (step S5706 to step S5709). 

Now, the first gateway 8002 describes both the destination 
IP address and the destination MAC address in the propose 
message (step S5710). 

The second gateway 8003 which is the receiving FANP 
node here is the FANP node compatible only with the MAC 
address, so that the second gateway 8003 refers to the MAC 
address field. Then, in order to notify that it is the FANP 
node compatible only with the MAC address, the second 
gateway 8003 returns the propose ACK message to the first 
gateway 8002 by describing only the MAC address (step 
S5711). 

The first gateway 8002 that received this propose ACK 
message can ascertain that the downstream side FANP node 
wishes the FANP by the MAC address. Consequently, the 
first gateway 8002 transmits the offer message containing 
the destination MAC address to the second gateway 8003 
which is the neighboring FANP node. This operation may be 
realized by setting the MAC address of the receiving ter- 
minal 8005 as the destination MAC address of the offer 
message, or by providing a new optional field in the FANP 
message (step S5712). 

The second gateway 8003 takes the FANP message into 
the FANP processing unit by referring to the protocol type 
field of the Ethernet frame. 

In this manner, the FANP processing is sequentially 
carried out up to the receiving terminal 8005 and the 
re-direct message is transmitted backwards sequentially, so 
as to complete the set up at each gateway. Finally, the 
transmitting terminal 8001 which received the re-direct 
message starts the video data transmission. By the above 
procedure, the reservation of the communication resource in 
the intermediate routes is carried out similarly as in the first 
to fourth embodiments, so that it becomes possible to realize 
the video data delivery while guaranteeing the communica- 
tion quality. 

Here, the At the first Ethernet 8012 and the second 
Ethernet 8013, the dedicated MAC address for video may be 
acquired as in the second embodiment, but it is also possible 
to carry out the bandwidth reservation by directly using the 
original MAC address (M. 2 in this case). In such a case, at 
the first Ethernet 8012 and the second Ethernet 8013, all the 
Ethernet frames with the MAC address destined to the 
receiving terminal 8005 described in the destination field 
will be frames for which the communication quality 
requested by the intermediate bridges (the second gateway 
8003 and the third gateway 8004) is guaranteed. 

Namely, the present invention uses a mechanism which is 
capable of reserving the necessary communication quality 
for each destination MAC address, even in a simple bridge 
connection type network. Also, this mechanism is a very 
flexible one in that the routing control and the communica- 
tion quality reservation as well as the corresponding datalink 
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layer control and connection can be realized end-to-end, in 
an environment in which the bridges and the routers, the IP 
address compatible FANP nodes, etc., are mixedly present 
(as in the first or fifth embodiment). 

Note that the five embodiments described above are 5 
mainly directed to the control based on the IP address. 
However, it should be apparent that the present invention is 
equally applicable to any address system that can bundle all 
kinds of networks, such as E.164, Colba, JAVAand extended 
OLE. 

Sixth Embodiment 

Referring now to FIG. 58 to FIG. 67, the sixth embodi- 
ment of the present invention will be described in detail. 

FIG. 58 shows an exemplary overall configuration of a 
network system according to the sixth embodiment, for an 
exemplary case of taking data from a video server that is 
providing a video service into a home network through a 
public network such that the video service is received at a 
terminal connected to the home network. 

20 

As shown in FIG. 58, this network system comprises a 
video server 7001, a public network (Internet) 7004, a 
connection device 7002, a first home network (IEEE 1394) 
7005, a second home network 7006, and a terminal 7003 
connected to the first home network 7005. Note that FIG. 58 25 
shows an exemplary case of connecting only one terminal 
7003 to the first home network 7005, but it is possible to 
connect various types of terminals or inter-networking con- 
nection device and the like to both of the home networks 
7005 and 7006 in practice. 30 

The public network 7004 can be provided in various 
forms including CATV network, ISDN/B-ISDN network, 
ATM-PON network, high speed radio access network, 
ADSL/HDSL network, etc., but it is assumed in this sixth 
embodiment that the video service provides MPEG video 35 
data through Internet (MPEG-over-IP). Consequently, an 
interface through which this service is provided is assumed 
to be a digital interface. 

In the following description, it is assumed that this digital 
network adopts ATM scheme as its datalink scheme, but the 40 
present invention is not limited to this particular case of 
using ATM scheme alone. For example, a datalink layer 
identifier such as VPI/VQ of ATM appearing in the follow- 
ing description corresponds to a B-channel identifier in the 
case of ISDN, or a frequency in the case of CATV. Thus the 45 
present invention encompasses those cases where VPI/VCI 
of ATM is replaced by any such other datalink layer iden- 
tifier. 

The video server 7001 can be a dedicated video server or 
a server that is capable of transmitting video signals such as 50 
a video handling WWW server for example. Here, "capable 
of transmitting video signals" does not necessarily implies a 
capability of real time transmission. For example, a case of 
delivering video data by best effort rather than real time 
delivery can be included. 55 

The public network 7004 and the home networks 7005 
and 7006 are connected at a dedicated connection device 
7002. In this case, the connection device 7002 has a function 
for terminating the public network 7004, a function for 
terminating the home networks 7005 and 7006, an IP pro- 60 
cessing function, a NAT (Network Address Translation) 
function which is standardized by RFC 1631, as well as an 
IP multicast handling function, an IP signaling function, a 
datalink layer level switch capable of realizing real time data 
transfer between the public network 7004 and the home 65 
networks 7005 and 7006, and an address notification 
function, as will be described in detail below. 



Next, IP subnet configuration and address assignment on 
the network system of FIG. 58 will be described. As shown 
in FIG. 58, in this sixth embodiment, one IP subnet (with a 
network address P) is formed by the home networks as a 
whole (first and second home networks 7005 and 7006), and 
in addition, private addresses standardized by RFC 1597 are 
utilized on the home networks. Also, a global IP address 
(G.2) is assigned to the public network side of the connec- 
tion device 7002. 

The reason for adopting such an address configuration is 
that acquisition of a plurality of global IP addresses requires 
higher cost compared with acquisition of one global IP 
address and there is a worldwide shortage of IP addresses. 
Namely, it is practically almost impossible to assign new 
global IP addresses to connection terminals of home net- 
works as a number of terminals and a number of addresses 
for home networks are expected to grow very rapidly. 

Note that the first home network 7005 and the second 
home network 7006 may belong to different subnets pro- 
vided that they use different private address systems. In such 
a case the connection device 7002 for inter-connecting them 
will be a router. In the following description, it is assumed 
that the first home network 7005 and the second home 
network 7006 belongs to the same subnet as described 
above. 

FIG. 59 shows a processing sequence in a case of carrying 
out video transfer from the video server 7001 to the terminal 
7003 through the connection device 7002 and the public 
network 7004, while FIG. 60 shows a processing sequence 
of the terminal 7003 in that case and FIG. 61 shows a 
processing sequence of the connection device 7002 in that 
case. 

As described in detail below, FIG. 59, FIG. 60 and FIG. 
61 are sequences in a case where the connection device 7002 
is an SBM (Subnet Bandwidth Manager) and this mecha- 
nism is used for reservation of communication resource. 
Here, SBM is a unit for carrying out reservation of com- 
munication resource within subnet by using RSVP, which is 
discussed in the IntServ working group of IETF. 

First, the terminal 7003 obtains information on a desired 
video using a protocol above layer 5 among seven layers 
standardized by OSI (steps S7201, S7203). This can be 
realized in various manners such as a negotiation using 
DSM-CC of MPEG/DAVIC or corresponding protocol, an 
information selection for selecting information from the 
WWW server on Web using RTSP, etc. In this sixth 
embodiment, these various manners are collectively referred 
to as an upper layer protocol, and it is assumed that the 
exchange of this information is realized by using IP packets. 

Note here that this upper layer protocol may be commu- 
nicated while being applied with NAT processing at the 
connection device 7002 (step S7202). Namely, in a case of 
forwarding an IP packet from a private IP network to 
Internet, it is not allowed to transmit a private IP address to 
Internet side, so that the connection device 7002 applies the 
NAT processing for translating a private IP address into a 
global IP address (G.2) of the connection device 7002 itself. 
For more detail of the NAT processing, see Japanese Patent 
Application No. 8-316552 (1996) for example. 

In this sixth embodiment, the video service from the video 
server is assumed to be provided through IP multicast. In this 
case, when a video to be selected is determined using the 
upper layer protocol, there is a need to obtain an IP multicast 
address for transferring that video. There are several pos- 
sible schemes that can be used for this broadcasting 
(delivery). 
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For example, there is a broadcasting scheme in which 
different IP multicast addresses are assigned to different 
videos (different video contents). This is a case of IP 
multicast address assignment in which a broadcast from a 
broadcast station A is assigned with an IP multicast address= 5 

a broadcast from a broadcast station B is assigned with 
an IP multicast address="#6" and so on, for example. 

The video server 7001 notifies a multicast address "M" to 
be used for video transfer to the terminal 7003 through the 
upper layer protocol. Then, the terminal 7003 transmits a 1° 
REPORT message for the multicast address "M" to be 
subscribed for, in response to a QUERY message received 
from Internet side, according to the IP multicast protocol 
(such as IGMP (Internet Group Management Protocol) 
(RFC 1112) for example) (step S7204). 15 

Upon receiving this message, the connection device 7002 
stores a correspondence between the private address "P.2" of 
the terminal 7003 and the requested multicast address "M" 
(step S7205), and notifies the REPORT message to the 
upstream side router (step S7206). At this point, the source 20 
address is set to be the global IP address "G.2" of the 
connection device 7002 itself. FIG. 62 shows an example of 
a correspondence table stored by the connection a device 
7002. 

25 

When the subscription for the multicast address "M" 
succeeds, the connection device 7002 stores the fact that the 
terminal 7003 has subscribed for the multicast address "M" 
(step S7205), and notifies this fact to the terminal 7003. 

Next, the terminal carries out the reservation of commu- 3Q 
nication resource in order to receive this video in good 
quality. There are several possible methods that can be used 
for this communication resource reservation including: 

(a) Method using SBM; 

(b) Method using RSVP (Resource Reservation Setup 35 
Protocol); and 

(c) Method using IEC 61663. 

Note that SBM (Subnet Bandwidth Manager) is a scheme 
for reserving bandwidth within subnet which is proposed in 
IETF, the standardization organization for Internet, in which 40 
the bandwidth reservation within subnet is carried out by 
using RSVP. FIG. 59 shows an exemplary case of using 
SBM. 

In this case, the connection device 7002 is an SBM node 
so that the routing protocol is not operating thereon. Note 45 
that the connection device 7002 of this embodiment has a 
NAT function so that it also has a global IP address (G.2), but 
even when there are plural physical interfaces on the home 
network side, there is no need for the connection device 
7002 to have IP address (private address) for each physical 50 
interface separately. For example, it suffices for the connec- 
tion device 7002 to have one private address in addition to 
the global IP address. In this embodiment, the connection 
device 7002 is assumed to have a private IP address "P.I". 

The terminal 7003 may urge the video server 7001 to 55 
transmit a PATH message of RSVP, by means of the upper 
layer protocol and the like. The PATH message will be 
transmitted with the multicast address "M" as destination, 
and arriving at the connection device 7002 (step S7207). 

The connection device 7002 creates a PATH state of 60 
RSVP (step S7208), and transmits this PATH message with 
the multicast address "M" as destination so that it eventually 
arrives at the terminal 7003 (step S7209). Here, the connec- 
tion device 7002 already recognizes that the terminal 7003 
belongs to the multicast address "M" from the correspon- 65 
dence table of FIG. 62, so that the connection device 7002 
can forward this PATH message to the terminal 7003. 
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In the connection device 7002, the PATH state is created. 
Here the connection device 7002 is an SBM node. The 
terminal 7003 transmits an RESV message of RSVP to the 
connection device 7002 of the upstream side so as to reserve 
communication resource such as bandwidth (step S7210). 

Upon receiving this RESV message, the connection 
device 7002 makes an access to an IEEE 1394 isochronous 
resource manager of the first home network (IEEE 1394) 
7005 and reserves necessary bandwidth and isochronous 
channel number, so as to reserve communication resource 
between the connection device 7002 and the terminal 7003 
(step S7211). An isochronous channel number reserved here 
is assumed to be "#x". 

At this point, the connection device 7002 may notify an 
information indicating 'isochronous channel that should be 
used for transmitting the requested program' to the terminal 
7003 (step S7212). 

There are several possible methods that can be used for 
this notification including the following. 

The first notification method is a method using a PATH 
message of RSVP in a format shown in FIG. 63. In this 
method, as shown in FIG. 63, an information indicating that 
'hereafter (or now), data (IP flow) contained in this PATH 
message will be transmitted by an isochronous channel 
number="#x"' is described within the PATH message of 
RSVP. 

The second notification method is a method using FANP 
(Flow Attribute Notification Protocol) as described in the 
first to fifth embodiments described above. Note that FANP 
notifies a correspondence between IP flow and the like (IP 
multicast address "M", for example, in the case of this 
embodiment) to be transmitted and a link layer ID informa- 
tion (IEEE 1394 channel number reserved earlier in the case 
of this embodiment), among neighboring nodes (the con- 
nection device 7002 and the terminal 7003 in the case of this 
embodiment). 

The third notification method is a method using CIP 
header of IEC 61663. In this method, the connection device 

7002 directly writes a channel number to be used into a PCR 
(Plug Control Register) of the terminal 7003 by using IEC 
61883, and makes the terminal 7003 recognize that the 
transmitted information is MPEG-over-IP by means of 1394 
header or a CIP (Common Isochronous Packet) header 
defined by IEC 61663. For example, in a case of extending 
the CIP header, a value indicating that this packet is IP 
packet or MPEG-over-IP packet is written into an FMP 
(Format ID) region, such that it becomes possible for the 
terminal 7003 to recognize an attribute of that packet as IP 
packet or IP packet with MPEG mounted thereon by looking 
at the CIP header. 

The fourth notification method is a method in which PCR 
is extended and the meaning of a part of PCR register is set 
to indicate contents to be transmitted through that channel 
number, as shown in FIG. 64. For example, a value indi- 
cating that this packet is IP packet or MPEG-over-IP packet 
may be described. Alternatively, an attribute of flow to be 
transmitted through that channel number may be described, 
in a form of combination of source IP address, destination IP 
address, source port number, and a destination port number, 
for example. By providing such a register in the terminal 

7003 and writing appropriate description into this register 
from the connection device 7002 (or controller), it becomes 
possible for the terminal 7003 to recognize that data to be 
received through that channel number is IP packet or 
MPEG-over-IP packet, or else an attribute of that data. 

It should be apparent that any of the first to fourth 
notification methods described above may be used in suit- 
able combination. 
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Note also that, as far as timing is concerned, apart from 
the timing described here, it is also possible to carry out the 
above described procedure at a stage where the reservation 
of communication resource up to the video server 7001 is 
completed so that the end-to-end communication becomes 5 
possible. 

Now, when the reservation of communication resource on 
the downstream side has succeeded, the connection device 
7002 passes the RESV message of RSVP to the further 
upstream side (step S7213). 10 

Upon receiving this message, a router within Internet 
reserves communication resource of ATM network on the 
downstream side by using Q.2931 and the like, for example 
(step S7214), and after confirming this reservation, transmits 
the RESV message to the further upstream side. This opera- 15 
tion is subsequently repeated by subsequent routers. 

In addition, the router transmits an information on a 
datalink identifier (VPI/VCI in this case as the datalink 
technology employed is ATM) to be used to an RSVP/SBM 
node of the downstream direction by using PATH or FANP, 20 
so as to notify a correspondence between IP flow to be 
transmitted and datalink identifier to that RSVP/SBM node 
(step S7215). A VCI value of ATM reserved for the con- 
nection device 7002 is assumed to be "#y". 

When the end-to-end communication resource is reserved 25 
in this manner, the video transfer is started (steps S7216, 
S7217). 

Here, the connection device 7002 already recognizes that 
data of MPEG-over-IP are to be transmitted from the video 
server 7001 through an ATM connection "#y (VCI="#y"), 30 
and that it suffices to transmit received IP packets to the 
terminal 7003 through an isochronous channel "#x" of IEEE 
1394. 

Thus the connection device 7002 transmits data received 
through VCI "#y" directly to the isochronous channel "#x" 35 
of IEEE 1394 without verifying header contents of IP 
packets, by establishing synchronization among IP packets. 
Namely, the connection device 7002 can carry out a direct 
data transfer to 1394 by verifying only VCI value without 
applying any IP layer processing. This can be viewed as a 40 
datalink switch since switching of data is made according to 
datalink layer information alone. 

As a consequence, an IP layer processing, that is a series 
of software processing such as IP header verification, rout- 
ing processing, etc., that would have been required at the IP 45 
layer otherwise can be replaced by a datalink layer switching 
processing, so that it becomes possible to reduce a process- 
ing time and a processing load considerably. This corre- 
sponds to a provision of effectuating SBM and then effec- 
tuating datalink switch. 50 

Note that the above description has been directed to a case 
where the connection device 7002 is as an SBM node, but 
it is also possible to carry out the reservation of communi- 
cation resource using RSVP in a case where the connection 
device 7002 is a router. 55 

It is also possible to carry out the above described 
reservation of communication resource by means of com- 
munication resource reservation using FANP as described in 
the first to fifth embodiment described above. 

Up to here, a case where the communication resource 60 
reservation on IEEE 1394 is carried out by an upstream side 
node of RSVP has been described. In contrast, the reserva- 
tion of an isochronous channel on IEEE 1394 bus may be 
carried out by a downstream side node (the terminal 7003 in 
the case of this embodiment), as indicated in FIG. 65. 65 

In FIG. 65, after the downstream side node carries out the 
reservation of an isochronous channel having necessary 
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communication resource (step S7110), an RESV message is 
transmitted to an upstream side (step S7111). The rest of 
FIG. 65 is substantially the same as FIG. 59. 

In this case, the reserved isochronous channel number and 
the like may be transmitted by including it in the RESV 
message of RSVP that is to be transmitted subsequently. 

Also, the notification to the upstream side of a correspon- 
dence between an isochronous channel number and a flow 
for which bandwidth reservation is to be made may be 
realized by using a message other than the RESV message. 
Namely, the RESV message may be used simply for the 
purpose of requesting the bandwidth reservation for that 
flow with respect to the connection device 7002, and the 
notification of the correspondence between an isochronous 
channel number and a flow for which bandwidth reservation 
Is to be made may be realized by using another message 
such as FANP message or by using PCR shown in FIG. 64. 
Upon receiving this notification, the connection device 7002 
can obtain from this message an information as to which link 
layer connection, that is isochronous channel, should be 
used for transferring a flow for which the bandwidth reser- 
vation has been made by the RESV message. 

Now, when the user at the terminal 7003 wishes to watch 
a different video (a TV program on a different channel, for 
example), the above described procedure is going to be 
repeated once again. Namely, this can be realized by repeat- 
ing a procedure of obtaining an IP multicast address corre- 
sponding to a new video through the upper level protocol 
and subscribing for that IP multicast address. At that time, it 
is preferable to secede from the previously subscribed IP 
multicast address from a viewpoint of efficient utilization of 
communication resource. FIG. 66 illustrates this process. 

Also, when plural terminals are connected to the home 
network and these terminals are watching different 
programs, their respective data are going to pass through the 
public network 7004 and the connection device 7002, and it 
is convenient from a viewpoint of the connection device 
7002 to have these data with different destination terminals 
transmitted through different ATM- VCs because the datalink 
switching is to be carried out at the connection device 7002. 
As for the reservation of communication resource, whether 
it is necessary to repeat the above described procedure using 
SBM, RSVP, FANP, etc. again or not depends on a manner 
of making reservation by RSVP/SBM. Namely, in a case of 
using Shared Explicit reservation, the same communication 
resource (VC of ATM, isochronous channel of 1394) as 
previously reserved can be used continually as long as the 
source video server is identical or as long as a new video 
server for transmitting a next video has been registered, and 
it suffices to make a subscription for IP multicast address 
again. 

Next, a case of another broadcasting scheme in which 
contents can be changed while the same IP multicast address 
is used will be described. In this case, a plurality of video 
services are going to be carried out with respect to the same 
user using the same multicast address, and a video contents 
change (corresponding to a TV channel change) is going to 
be carried out by using the upper level protocol. 

In this case, the same procedure as described above is also 
to be carried out up to the initial communication resource 
reservation. Here, however, the IP multicast address given 
through the upper layer protocol can be an IP multicast 
address uniquely given to that terminal in advance (IP 
multicast address assigned to each terminal or user by a 
network service provider in advance). The identification of 
the terminal can be realized by the upper layer protocol 
using an identifier assigned to each terminal by a network 
service provider in advance, for example. 



US 6,751 

67 

At a time of next contents change (corresponding to TV 
channel change), the terminal requests this contents change 
by using the upper layer protocol. The video server 7001 
continues to use the currently used IP multicast address 
without any change, and transmits the changed contents to 5 
that IP multicast address. 

Similarly as described above, it is not absolutely neces- 
sary to use this IP multicast address for the purpose of 
multicast, and it is possible to use this IP multicast address 
for contents transfer with respect to a single terminal, as 10 
illustrated in FIG. 67. Namely, one multicast address is 
assigned to one user (terminal) from which a video delivery 
request has been made, and a change of contents to be 
transmitted is handled by the upper layer protocol, for 
example. 15 

It is also possible to trigger the judgement as to whether 
or not to assign different multicast addresses by looking at 
a difference in the port number of an IP packet transmitted 
from the connection device 7002. 

As such, by assigning different IP multicast addresses to 20 
different users or applications, it is possible to realize 
dynamic assignment of IP multicast addresses with respect 
to terminals and therefore it becomes possible to transmit 
various contents to the terminal having a private address, 
without worrying about an overlap with the globally unique 25 
IP address, even under the private address environment. 

Note that the sixth embodiment has been described for an 
exemplary case of realizing transfer of IP multicast data flow 
by reserving bandwidth using RSVP, but it should be appar- 
ent that the scheme of this sixth embodiment is equally 30 
applicable to IP uni-cast as well as to a uni-cast or multicast 
at another network layer. 

As described, according to this sixth embodiment, a 
scheme for applying RSVP to IEEE 1394 bus is specified in 
view of the conventionally encountered problem that a 35 
scheme for operating a network layer signaling protocol 
such as RSVP on IEEE 1394 has not been standardized and 
a straightforward mapping causes no guaranteed communi- 
cation quality on IEEE 1394 and no guaranteed end-to-end 
communication quality, so that it becomes possible to realize 40 
communication that guarantees communication quality in an 
inter-connected network environment even on IEEE 1394. 

Seventh Embodiment 

Referring now to FIG. 68 to FIG. 83, the seventh embodi- 45 
ment of the present invention will be described in detail. 

FIG. 68 shows an exemplary overall configuration of a 
network system according to the seventh embodiment, in 
which an IGMP (Internet Group Management Protocol) 
router 7101, an isochronous resource manager 7104 of IEEE 50 
1394, and receiving terminals 7102 and 7103 are inter- 
connected through an IEEE 1394 bus so as to enable 
communications among them. 
(7-1) 

Now, a case where the terminals 7102 and 7103 receive 55 
multicast data by subscribing for IP multicast in the network 
system of FIG. 68 will be described. Here, after subscribing 
for IP multicast, the terminals 7102 and 7103 become 
receiving terminals of multicast data so that these terminals 
will be referred to as receiving terminals 7102 and 7103. 60 

FIG. 69 shows a procedure by which the receiving ter- 
minals 7102 and 7103 subscribe for IP multicast, and FIG. 
70 shows a processing procedure of the IGMP router 7101 
in that procedure. 

As shown in FIG. 68, the IGMP router 7101, the receiving 65 
terminals 7102 and 7103, and the isochronous resource 
manager 7104 are connected on the IEEE 1394 bus. Here it 
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is assumed that the receiving terminal 7102 has an IP 
address "IPl" and the receiving terminal 7103 has an IP 
address "IP2". Note that functions of the isochronous 
resource manager 7104 may be provided integrally within 
any of the other three elements of FIG. 68 (that is, any one 
of the IGMP router 7101 and the receiving terminals 7102 
and 7103 may play a role of the isochronous resource 
manager). It is also assumed that the receiving terminals 
7102 and 7103 already obtained an IP multicast address 
"IPm" in advance by some suitable means. 

First, suppose that the receiving terminal 7102 is wishing 
to subscribe for the IP multicast address "IPm". To this end, 
an exchange of IGMP message (transmission and reception 
of IGMP QUERY, IGMP REPORT, etc.) is carried out 
between the IGMP router 7101 and the receiving terminal 
7102, such that the receiving terminal 7102 notifies that it is 
wishing to subscribe for the IP multicast address "IPm" to 
the IGMP router 7101 (step S8101 of FIG. 69). Here, the 
IGMP router 7101 is assumed to be a router capable of 
supporting this IP multicast address "IPm". This IGMP 
router 7101 may be something like a set-top box. Namely, 
the IGMP router 7101 may be a node having a function for 
extracting packets destined to the appropriate IP multicast 
address from IP multicast packets transmitted by broadcasts, 
and then forwarding the extracted packets. 

Upon receiving a request of subscription for the IP 
multicast address "IPm" from the receiving terminal 7102, 
the IGMP router 7101 executes the processing according to 
the flow chart of FIG. 70. Namely, in this seventh 
embodiment, a subscription request from the receiving ter- 
minal 7102 is an initial subscription request for the IP 
multicast address "IPm" from its subnet (IEEE 1394 bus), so 
that the IGMP router 7101 carries out a prescribed process- 
ing procedure for subscription for IP multicast address (steps 
S8201 to S8203 of FIG. 70). When this processing proce- 
dure is successfully completed, the IGMP router 7101 makes 
an access to the isochronous resource manager 7104 and 
reserves an isochronous channel number (steps S8204 and 
S8205 of FIG. 70, step S8102 of FIG. 69). Note that, at the 
step S8203 of FIG. 70, the IGMP router 7101 may carry out 
the procedure for subscription for this IP multicast address 
by acting on another IGMP router on a further upstream side. 
When this processing procedure for subscription fails, the 
IGMP router 7101 notifies that fact to the receiving terminal 
7102 (step S8209 of FIG. 70). 

Here, the isochronous channel number reserved by the 
isochronous resource manager 7104 in response to a request 
from the IGMP router 7101 at the step S8205 of FIG. 70 is 
assumed to be "#x". Note that it is not absolutely necessary 
to reserve bandwidth at this point because what is reserved 
at this point is an asynchronous stream of IEEE 1394. The 
asynchronous stream is a packet in an isochronous packet 
format which is to be transmitted at asynchronous arbitration 
time, for which only the isochronous channel number is 
reserved through the isochronous resource manager 7104. A 
case where it is necessary to reserve bandwidth will be 
described later. 

Returning now to FIG. 70, when the isochronous channel 
number is reserved, the IGMP router 7101 writes an infor- 
mation on this IP multicast flow into own layer-3 flow 
register (step S8206 of FIG. 70, step S8103 of FIG. 69). 

FIG. 71 shows an exemplary format of the layer-3 flow 
register. As shown in FIG. 71, the layer-3 flow register is 
basically a register for registering a correspondence between 
a layer-2 ID (an isochronous channel number in the case of 
this seventh embodiment) and a layer-3 flow that is going to 
pass through a channel indicated by that layer-2 ID. In 



US 6,751 

69 

addition to that, this register also have regions for registering 
an information as to whether that flow is to be inputted or 
outputted, an amount of bandwidth reserved for the channel 
indicated by that layer-2 ID, a counter for counting a number 
of terminals that are using that channel, etc. As shown in 5 
FIG. 71, no bandwidth is reserved for the reserved channel 
in this case, so that the bandwidth field of the layer-3 flow 
register has a value "0" entered therein, for example. 

The IP flow with the IP multicast address "IPm" as 
destination will be flowing into this channel so that, for the 10 
flow ID, "IPm" is entered as a destination IP address and a 
specified port number (PORT1 for example) when an avail- 
able port number is limited or a value "0" when an available 
port number is not limited is entered as a destination port 
number. In the case of this seventh embodiment, an available 15 
port number is not limited so that a value "0" is entered into 
the destination port number. Also, the source terminal is not 
specified in a case of IP multicast address, so that a value "0" 
is entered as a source IP address and a source port number. 

For the layer-2 ID, "IEEE 1394" is entered as a layer-2 20 
type, "isochronous channel number is entered as an ID type, 
and the isochronous channel number "#x" that is reserved 
earlier is entered as an ID in this case. 

As for direction, "output" is entered on an assumption that 
basically this IGMP router transmits these IP multicast 25 
packets. 

The connection counter is a counter for indicating a 
number of nodes that can be regarded as receiving this 
asynchronous stream. The receiving terminal 7102 is a sole 
receiver at this point, so that a counter value "1" is entered 30 
into the connection counter. 

Note that this layer-3 flow register may be realized in a 
form of a combination of a plug control register used in IEC 
61663 and a register for storing an information on the 
layer-3 flow to be transferred through that channel. 35 

Next, the IGMP router 7101 writes the same information 
as that of FIG. 71 into the layer-3 flow register of the 
receiving terminal 7102, except that the direction parameter 
is changed from "output" to "input" (step S8207 of FIG. 70, 
step S8104 of FIG. 69). 40 

As the correspondence between the layer-3 flow informa- 
tion and the layer-2 ID is written into the layer-3 flow 
register of the receiving terminal 7102 in this manner, it 
becomes possible for the receiving terminal 7102 to recog- 
nize hereafter that the channel number "#x" of the asyn- 45 
chronous stream is allocated for IP multicast with IP mul- 
ticast address "IPm" as destination. Then, it suffices for the 
receiving terminal 7102 to receive the channel number "#x" 
of the asynchronous stream in order to receive datagrams 
destined to the IP multicast address "IPm" (step S8105 of 50 
FIG. 69). 

Note that, in the above, the layer-3 flow register of the 
receiving terminal 7102 also registers an information as to 
whether an IP flow coming from the asynchronous stream or 
the isochronous channel indicated by the channel number is 55 
to be inputted or outputted, but it is also possible to provide 
separate layer-3 flow registers for input and output and use 
them properly. 

Returning now to FIG. 69, suppose that the receiving 
terminal 7103 is now wishing to subscribe for the same IP 60 
multicast address "IPm". Then, the processing procedure for 
subscription by the IGMP is carried out between the IGMP 
router 7101 and the receiving terminal 7103 (step S8106 of 
FIG. 69). 

Then, the IGMP router 7101 carries out a processing 65 
shown in FIG. 70. Namely, the IGMP router 7101 already 
started service for this IP multicast address "IPm" so that the 
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IGMP router 7101 increments the connection counter of the 
own layer-3 flow register is incremented (to a counter value 
"2", for example) (step S8208 of FIG. 70), and writes the 
same information as previously written into the layer-3 flow 
register of the receiving terminal 7102 now into the layer-3 
flow register of the receiving terminal 7103 so as to notify 
the correspondence between the channel number and the IP 
flow (step S8207 of FIG. 70). 

Note that a number of terminals subscribing for the IP 
multicast address "IPm" is comprehended by the IGMP 
router 7101 and it is not absolutely necessary for each 
terminal to comprehend this, so that the connection counter 
value written into the layer-3 flow registers of the receiving 
terminals 7102 and 7103 may be a value "1" for example. 

Up to here, a procedure for subscribing for IP multicast 
address has been described. Next, the operation of the IGMP 
router 7101 in a case of secession will be described with 
reference to FIG. 72. 

In the case of secession, when a procedure for secession 
from the IP multicast address "IPm" is received from either 
receiving terminal (step S8301), or when a keep alive signal 
IGMP REPORT indicating that receiving of the IP multicast 
address "IPm" is continuing from either receiving terminal 
is not received over a prescribed period of time (step S8302), 
the IGMP router 7101 Judges that this terminal wishes to 
stop receiving the IP multicast address "IPm", and decre- 
ments the connection counter value of the own layer-3 flow 
register (step S8303). 

The connection counter value written in the layer-3 flow 
register of the IGMP router 7101 indicates a number of 
terminals subscribing for the IP multicast address "IPm" on 
that IEEE 1394 bus, so that when this value becomes "0" 
(step S8304), the IGMP router 7101 Judges that there is no 
terminal which is receiving the IP multicast address "IPm" 
on that IEEE 1394 bus, and secedes from that IP multicast 
address "IPm" (step S8305). 

In parallel to this, in order to notify the secession to the 
seceded terminal, the IGMP router 7101 may carry out an 
operation to write all "0" values, for example, into the 
layer-3 flow register of the seceded terminal. 

Note that by maintaining the information on the IP 
multicast address as well as values of the layer-3 flow 
register even when a bus reset is caused in the IEEE 1394 
bus in a course of IP multicast address subscription or a 
series of processing after the subscription, it becomes pos- 
sible to realize a quick recovery of the IP multicast datagram 
receiving. 

Note also that all packets destined to the IP multicast 
address "IPm" are going to be transmitted and received 
through the asynchronous stream indicated by the channel 
number "#x". Here, control packets of IGMP and the like 
may be communicated by using the asynchronous stream 
corresponding to that multicast address, default asynchro- 
nous stream (ARP (Address Resolution Protocol)), or asyn- 
chronous stream channel or asynchronous broadcast allo- 
cated for the purpose of IP broadcast or the like. 

Also, either default asynchronous stream or asynchronous 
write broadcast is to be used as a channel for transmitting 
control packets of IGMP and IP packets and the like with a 
destination address indicating all hosts such as IP address= 
"224. 0. 0. 1" for example, at a time of IP multicast 
subscription. 

Next, a case of changing IP multicast into a state of "using 
bandwidth (QOS)", that is, a case of assigning bandwidth to 
the asynchronous stream and using it for transmission and 
reception, will be described with reference to FIG. 73. 
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Up to a point where the receiving terminal 7102 becomes 
capable of receiving datagrams destined to the IP multicast 
address "IPm" (steps S8501 to S8504), the procedure is the 
same as the steps S8101 to S8105 of FIG. 69 described 
above. 5 

When a transmission using bandwidth is possible for this 
IP multicast, the IGMP router 7101 sends a PATH message 
of RSVP to the receiving terminal (the IP multicast address 
"IPm") (step S8505). 

In response, the receiving terminal 7102 which wishes to 10 
receive this IP multicast in a state of "using bandwidth" 
sends an RESV message of RSVP to the upstream side (i.e., 
the IGMP router 7101) so as to request a reservation of 
bandwidth (step S8506). 

In RSVP which is an example of bandwidth reservation 15 
protocols on IP, a transmitting host (an upstream side node) 
transmits a PATH message along with data. Communication 
bandwidth and the like are basically set up by this trans- 
mitting host. In contrast, the receiving terminal which 
wishes to make bandwidth reservation transmits an RESV 20 
message with the transmitting node as destination. In 
general, a router monitors the RESV message corresponding 
to the PATH message, and executes the bandwidth reserva- 
tion when the RESV message is detected. Here it is assumed 
that the above described correspondence between the IP 25 
multicast address and the channel is already set up. 

When the RESV message from the receiving terminal 
7102 is detected, the IGMP router 7101 makes an access to 
the isochronous resource manager 7104 and reserves band- 
width. When the bandwidth is successfully reserved, an 30 
information on reserved bandwidth (an amount of band- 
width y) is entered into the layer-3 flow registers of its own 
and the receiving terminal 7101, so as to notify the success 
of bandwidth reservation (steps S8507 and S8508). 

Thereafter, transfer of datagram destined to the IP multi- 35 
cast address "IPm" is continued using the isochronous 
channel (channel number "#x") for which bandwidth is 
reserved (step S8509). 

Note that, when there are plural receiving terminals at this 
point, the IGMP router 7101 may rewrite a bandwidth 40 
portion of the layer-3 flow register of each receiving termi- 
nal. It is also possible to adopt a scheme in which the 
rewriting of the layer-3 flow register of the receiving termi- 
nal is not carried out as it becomes tedious when there are 
many receiving terminals, and the rewriting is carried out 45 
only in the layer-3 flow register of its own (IGMP router 
7101). 

As described, in a case of assigning bandwidth to the 
asynchronous stream, it is possible to avoid the so called 
double reservation of bandwidth in which plural receiving 50 
terminals reserve bandwidth for the same channel at the 
same time, by following the rule that the reservation of 
bandwidth is carried out by a node that transmits QOS 
packets. Moreover, it is expected that the transmitting node 
is usually comprehending a value of necessary bandwidth in 55 
most cases so that this rule is appropriate in view of this fact 
as well. 
(7-3) 

Now, in the above, the correspondence between the IP 
multicast flow and the channel number of isochronous 60 
channel or asynchronous stream through which that flow 
passes has been notified by using the layer-3 flow register, 
but it is also possible to realize this notification by using 
FANP. Note that FANP is a protocol for notifying a corre- 
spondence between some datalink layer channel (such as 65 
isochronous channel or asynchronous stream of IEEE 1394 
or virtual channel of ATM or frame relay, etc.) and an upper 
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layer flow (such as IP flow) that pass through that channel, 
by using IP datagrams. 

FIG. 74 shows a processing procedure in this case. When 
the receiving terminal 7102 wishes to subscribe for the IP 
multicast address "IPm", the subscription procedure using 
IGMP is carried out similarly as in the case of FIG. 69 
between the receiving terminal 7102 and the IGMP router 
7101 (step S8601). The IGMP router 7101 then makes an 
access to the isochronous resource manager 7104 in order to 
reserve a channel for this IP multicast address "IPm", and 
reserves the channel number "#x" (step S8602). 

Next, the IGMP router 7101 uses the plug control register 
of IEEE 1394 and FANP in order to notify that TP multicast 
"IPm" will be offered through channel "#x"' to the receiving 
terminal 7102. 

The plug control register is a register that has an effect of 
urging reception or transmission of isochronous channel/ 
asynchronous stream provided by using some channel 
number, and the plug control registers for input and output 
are provided separately. Using this plug control register, the 
IGMP router 7101 urges the receiving terminal 7102 to 
receive the channel "#x" (step S8603). Note that, at this 
point, the IGMP router 7101 may carry out writing into the 
own plug control register as well. In such a case, a number 
of receiving terminals of that IP multicast address can be 
entered into the connection counter according to the same 
rule as described above. By means of this, it becomes 
possible to comprehend a number of nodes that are receiving 
that multicast from that channel. 

Next, the IGMP router 7101 sends a message as shown in 
FIG. 75 as a FANP OFFER message to the receiving 
terminal 7102. This FANP message has the IP multicast 
address "IPm" as destination, and sent through a broadcast 
channel for layer-3 packets allocated to IEEE 1394 bus 
(packets of a specific asynchronous stream or packets with 
node ID=all "1" as destination, for example). 

As shown in FIG. 75, the FANP OFFER message contains 
a flow ID and a layer-2 ID, and notifies a correspondence 
between the above described layer-2 ID (channel number 
"#x" in the case of this embodiment) and an upper layer flow 
provided through a channel indicated by this layer-2 ID (IP 
multicast address "IPm" in the case of this embodiment) 
(step S8604). 

Thereafter, transmission of datagrams destined to the IP 
multicast address "IPm" is carried out through this channel 
"#x" (step S8605). 

Similarly, when there is a subscription request from the 
other receiving terminal 7103 (step S8606), the notification 
of the correspondence can be realized by carrying out the 
writing into the plug control register (step S8607) and the 
sending of the FANP message (step S8608). 

Note that the FANP message in this case is destined to the 
IP multicast address so that even when there are plural 
receiving terminals it is not absolutely necessary to send the 
FANP message to each one of the receiving terminals one by 
one, and it suffices to transmit the datagram destined to the 
IP multicast address "IPm" Just once, so that it is advanta- 
geous from a viewpoint of reduction of traffic on IEEE 1394 
bus. 

Now, in this embodiment, the correspondence between 
the layer-2 ID and the layer-3 flow has been notified by using 
the plug control register and the FANP OFFER message. 
Here, the notification of the above described correspondence 
cannot be realized unless the FANP message is used, but the 
receiving terminal can be made to carry out reception of data 
from this isochronous channel by writing into the plug 
control register, so that when it is not absolutely necessary 
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to notify the above described correspondence, the above 
described sending of the FANP message may be omitted. 
Conversely, when there is a FANP message, it becomes 
possible for the receiving terminal to recognize which 
layer-3 flow is going to be inputted from which channel 5 
number, so that the above described writing into the plug 
control register may be omitted if desired. 

Next, a processing procedure in a case where a plurality 
of flows are to be transmitted by using the same IP multicast 
address will be described with reference to FIG. 76. 

FIG. 76 shows a case of transmitting multicast packets 
with the IP multicast address "IPm" from the IGMP router 
7101 to the receiving terminal 7102, where two flows 
including a flow indicated by the port number "PORTT' 
(step S8804) and a flow indicated by the port number 15 
"PORT2" (step S8805) are to be transmitted simultaneously. 

The subscription for multicast address by IGMP (step 
S8801) and the reservation of isochronous channel number 
by the IGMP router 7101 (step S8802) are the same as 
described above. 20 

At a time of carrying out the writing into the layer-3 flow 
register at the step S8803, a flow to be transmitted by the 
asynchronous stream indicated by the isochronous channel 
number "#x" reserved at the step S8802 is not particularly 
specified, and only the fact that packets of the IP multicast 2 s 
address "IPm" are going to be transmitted is specified, so 
that both flows of the steps S8804 and S8805 are going to be 
transmitted by the asynchronous stream indicated by the 
channel number "#x". 

Now, suppose that the IGMP router 7101 permits trans- 
mission using QOS for a flow represented by "PORTT' 
among these two flows. For this reason, the IGMP router 
7101 sends a PATH message of RSVP with the IP multicast 
address "IPm" as destination (step S8806). In response, the 
receiving terminal 7102 sends an RESV message so as to 
request bandwidth reservation (step S8807). Then, the IGMP 35 
router 7101 makes an access to the isochronous resource 
manager 7104 and reserves necessary bandwidth specified 
by the RESV message. Here, the reserved amount of band- 
width is assumed to be "y" (step S8808). 

Then, the IGMP router 7101 carries out the writing into 40 
the layer-3 flow register of the receiving terminal 7102 in 
order to notify the receiving terminal 7102 that data with the 
amount of bandwidth "y" are going to be transmitted 
through the isochronous channel number "#x" at arbitration 
period of the isochronous channel (step S8809). At this step 45 
S8809, the notification to the receiving terminal 7102 is not 
necessarily limited to the above described case of using the 
layer-3 flow register, and it is also possible to realize this 
notification by using FANP or plug control register of IEC 
61663 as described above. Which scheme is to be adopted 50 
depends on requirements of the system. 

Subsequently IP multicast data from the IGMP router 
7101 are transmitted through the asynchronous stream for 
the flow represented by "PORT2" for which bandwidth is 
not reserved (step S8811), similarly as in the case of the step 55 
S8805, and through the isochronous channel (at arbitration 
period of the isochronous channel) for the flow represented 
by "PORTl" for which bandwidth is reserved (step S8810). 

Now, at the IGMP router 7101, there is a possibility for 
introducing IP multicast data (IP multicast packets destined 60 
to "IPm") with bandwidth greater than the amount of 
bandwidth "y" reserved for the isochronous channel "#x". 
However, it is not preferable to let these packets flow 
through the isochronous channel "#x" as they are because 
these IP multicast packets would additionally consume as 65 
much communication resource as bandwidth which has not 
been reserved. 
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For this reason, it is possible to use an algorithm shown 
in FIG. 77 which establishes a rule that a part for which 
bandwidth has been reserved is to be transmitted through the 
isochronous channel (steps S2901 and S2902) while a part 
for which bandwidth has not been reserved is to be trans- 
mitted through the asynchronous stream (step S2901 and 
S2903), so as to prevent the IGMP router 7101 to let those 
data with an amount of bandwidth greater than reserved one 
flow through the isochronous channel. In FIG. 77, "T-spec" 
refers to a traffic parameter specified at a time of reservation 
by RSVP, and it is also possible to specify a peak rate, a 
depth of bucket in the leaky bucket, etc. 

FIG. 78 shows an exemplary configuration for realizing 
the mechanism of FIG. 77. Here, WFQ stands for Weighted 
Fair Queueing, which is a packet scheduling scheme in 
which a ratio of amounts of packets to be transmitted for 
respective flows is set equal to a ratio of values (called 
weights) specified for respective flows in advance, in a case 
where one output port is to be shared by a plurality of 
packets from a plurality of senders/flows. 

In FIG. 78, a WFQ processing unit 7201 enters a packet 
which satisfies the T-spec into an isochronous queue 7202 
and a packet which does not satisfy the T-spec into an 
asynchronous queue 7203 according to this WFQ 
scheduling, and data queued in the isochronous queue 7202 
are transmitted at isochronous arbitration period via a packet 
transmission unit 7204 while data queued in the asynchro- 
nous queue 7203 are transmitted at asynchronous arbitration 
period via the packet transmission unit 7204. 

In the above, a scheme for using the same value for the 
isochronous channel number continually even when band- 
width is reserved has been described. In contrast, it is also 
possible to adopt a scheme which reserves another isochro- 
nous channel ("#z") different from the isochronous channel 
("#x") used for the asynchronous stream, with respect to a 
channel for which bandwidth reservation is necessary. 

A processing procedure for this case will now be 
described with reference to FIG. 79. 

In FIG. 79, the steps S9101 to S9107 up to a point where 
a request (RESV) for bandwidth reservation from the receiv- 
ing terminal 7101 is received by using RESV message of 
RSVP are the same as the steps S8801 to 8807 of FIG. 76. 

When the bandwidth reservation request is received at the 
step S9107, the IGMP router 7101 reserves an isochronous 
channel number "#z" different from the channel number 
"#x" of the asynchronous stream used up until then and an 
amount of bandwidth "y" (steps S9108 and S9019). This 
case also obeys the rule that "a sender (that is, the IGMP 
router 7101 in the case of this embodiment) reserves nec- 
essary link layer bandwidth". 

Then, the IGMP router 7101 writes that a flow represented 
by "PORT1" will be transmitted through an isochronous 
channel (rather than asynchronous stream) indicated by the 
isochronous channel number "#z", into the layer-3 flow 
register of the receiving terminal 7102, so as to notify the 
receiving terminal 7102 (step S9110). Note that, at the step 
S9111, the notification to the receiving terminal 7102 is not 
necessarily limited to the above described case of using the 
layer-3 flow register, and it is also possible to realize this 
notification by using FANP or plug control register of IEC 
61663 as described above. 

Thereafter, among the packets destined to the IP multicast 
address "IPm", a flow represented by "PORT1" is transmit- 
ted by the isochronous channel with the isochronous channel 
number "#z" (step S9111) while the other flows continue to 
be transmitted by the asynchronous stream (step S9112). 
(7-5) 
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Next, a case of handling plural senders of multicast data 
using asynchronous stream or isochronous channel indicated 
by one channel number will be described with reference to 
FIG. 80. Here, after subscribing for IP multicast, the termi- 
nals 7102 and 7103 of FIG. 68 become transmitting and 5 
receiving terminals of multicast data, and these terminals 
will be referred to as terminals A and B in the following. 

FIG. 80 shows a case where two terminals including the 
terminal A (IP address "IP1", 1394 address "FW1") and the 
terminal B (IP address "IP2", 1394 address "FW2") are 10 
transmitting IP multicast packets with respect to the same IP 
multicast address "IPm". Here, the 1394 address indicates an 
ID by which each terminal can be uniquely identified on that 
IEEE 1394 bus, such as a node ID of IEEE 1394, for 
example. 15 

In FIG. 80, the steps S9201 to S9204 and S9206 to S9208 
for the subscription for multicast, the reservation of channel 
number, and the notification of the correspondence between 
the IP multicast address and the channel number are the 
same as those in FIG. 69. 20 

What is characteristic in FIG. 80 is that each of the 
terminals A and B transmits an IP multicast packet by 
attaching an own source address ("FW1" or "FW2") through 
the channel indicated by the same channel number "#x" 
(step S9205, S9209 and S9210). This source address is 25 
written into a header called fragment header, which is a 
header given to each fragmented piece at a time of frag- 
menting an IP packet into 1394 frames. 

FIGS. 81A and 81B show exemplary configuration of IP 
multicast data transmitted from the terminals A and B, 30 
respectively. As shown in FIGS. 81A and 81B, these IP 
multicast data are formed by encapsulating an IP multicast 
packet (or its fragment) 7301 or 7304 by using a fragment 
header containing the source address to yield fragment data 
7302 or 7305, and then housing this fragment data 7302 or 35 
7305 inside a 1394 frame 7303 or 7306 (which is an 
isochronous frame in this case). 

The receiver is going to receive packets from a plurality 
of senders out of the asynchronous stream indicated by the 
same channel number, but as the source address is attached 40 
to each frame as described above, it is still possible for the 
receiver to re-assemble each packet accurately by referring 
to the source address. 

Up to here, a case of transmitting IP multicast packets 
from plural senders with respect to the same IP multicast 45 
address without using bandwidth reservation has been 
described. Now, a case of transmitting IP multicast packets 
from plural senders with respect to the same IP multicast 
address while using bandwidth reservation will be described 
with reference to FIG. 82. 50 

In FIG. 82, it is assumed that the IP multicast packets 
destined to the same IP multicast address "IPm" are trans- 
mitted from two senders, i.e., the terminals A and B, in a 
form of asynchronous stream, as a result of completing a 
procedure of steps S9201 to S9210 of FIG. 80, for example 55 
(steps S9401 and S9402). 

Here, when the terminal A is requested to transmit IP 
multicast data in a form of using bandwidth in some way (as 
in a case where RESV of RSVP is received, for example), or 
when the terminal A itself selects to transmit data in a form 60 
of using bandwidth, the terminal A makes an access to the 
isochronous resource manager 7104 to reserve a desired 
amount of bandwidth (yl) (step S9403), and thereafter the 
terminal A transmits IP multicast packets through the iso- 
chronous channel with the reserved amount of bandwidth yl 65 
at the isochronous arbitration period (step S9404). Here, the 
terminal B that has not reserved bandwidth continues to 
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transmit IP multicast packets by the same channel number 
"#x", but as the asynchronous stream at the asynchronous 
arbitration period (step S9405). 

In a case where the terminal B also transmits IP multicast 
packets in a form of using bandwidth, the terminal B also 
makes an access to the isochronous resource manager 7104 
to reserve a desired amount of bandwidth (y2) (step S9406), 
and transmits IP multicast packets through the isochronous 
channel with the reserved amount of bandwidth y2 at the 
isochronous arbitration period (step S9408). 

In a case of cancelling the previously reserved bandwidth, 
a request for cancellation of that bandwidth is made with 
respect to the isochronous resource manager 7104 (step 
S9409) and packet transmission at the isochronous arbitra- 
tion period is stopped. If there is a packet to be transmitted, 
this packet is transmitted by the asynchronous stream (at the 
asynchronous arbitration period) (step S9410). 

On the other hand, in a case of transmitting IP multicast 
in a form of using bandwidth, it is also possible to adopt a 
scheme which transmits IP multicast packets through an 
isochronous channel with a channel number "#z" which is 
different from a channel number "#x" used by the asynchro- 
nous stream. Aprocessing procedure in this case will now be 
described with reference to FIG. 83. 

In FIG. 83, it is assumed that the IP multicast packets 
destined to the same IP multicast address "IPm" are trans- 
mitted from two senders, i.e., the terminals A and B, in a 
form of asynchronous stream, as a result of completing a 
procedure of steps S9201 to S9210 of FIG. 80, for example 
(steps S9501 and S9502). 

Here, when the terminal A is requested to transmit IP 
multicast data in a form of using bandwidth by means of 
RESV message of RSVP and the like (as in a case shown in 
FIG. 83 where an RESV message of RSVP is received from 
the terminal B in response to a PATH message of RSVP from 
the terminal A, for example), the terminal A makes an access 
to the isochronous resource manager 7104 to reserve an 
isochronous channel number "#z" and a desired amount of 
bandwidth (yl) (steps S9503 to S9506). 

Then, the terminal A transmits a FANP message for 
notifying the correspondence between the reserved isochro- 
nous channel number and a flow to be transmitted through 
that isochronous channel, to that IP multicast address "IPm" 
through the asynchronous stream "#x" or a default asyn- 
chronous stream, for example (step S9507). A node which 
received this FANP message becomes possible to recognize 
which flow is going to be inputted in what characteristic 
from which isochronous channel. Note that, as described 
above, the notification of the correspondence is realized by 
using the FANP message here but it is also possible to realize 
this notification by using the layer-3 flow register or the plug 
control register of IEC 61663. 

As described, according to this seventh embodiment, it 
becomes possible to carry out IP multicast by utilizing 
communication resource efficiently, and to enable recogni- 
tion of correspondence between reserved channel and IP 
multicast address at a transmitting side and a receiving side 
in synchronization, in a network of broadcast type such as 
IEEE 1394. 

Note also that the present invention has been described 
above with the current Internet (i.e. IPv4) in mind, but it 
should be apparent that the present invention is equally valid 
in the next generation Internet (i.e. IPv6). 

As described, when a network is formed by connecting 
the communication terminal devices, relay devices, IEEE 
1394 inter-connection cable according to the present 
invention, it becomes possible to realize a large scale and 



US 6,751 

77 

multifarious (i.e. capable of using various networks) imple- 
mentation of the home network containing the 1394 bus. 
Moreover, this scheme has a great affinity with the public 
network and the Internet. 

It is to be noted that, besides those already mentioned 5 
above, many modifications and variations of the above 
embodiments may be made without departing from the 
novel and advantageous features of the present invention. 
Accordingly, all such modifications and variations are 
intended to be included within the scope of the appended 
claims. 

What is claimed is: 

1. A data transmitting node connected with a physical 
network, comprising: 

a first transmission unit for transmitting a control message 
in a case of transmitting information data to a receiving 
node connected with the physical network or another 
physical network, the control message including an IP 
(Internet Protocol) address information of a data trans- 
mission destination, a header or channel information 

. 20 
dependent on the physical network, and a layer indi- 
cation information indicating that the information data 
to be transmitted according to the header or channel 
information is data in an upper layer of an IP layer; and 

a second transmission unit for transmitting the informa- 25 
tion data to the receiving node, the information data 
containing the header or channel information and data 
of the upper layer without IP packet encapsulation. 

2. The data transmitting node of claim 1, wherein the 
control message commands to a network inter-connection 3Q 
node for connecting said physical network and a next 
physical network a registration of a correspondence between 
the header or channel information dependent on said physi- 
cal network and a header or channel information dependent 
on the next physical network. 35 

3. The data transmitting node of claim 1, further com- 
prising: 

a reception unit for receiving digital video and/or digital 
audio data; 

wherein the second transmission unit transmits the digital 40 
video and/or digital audio data received by the recep- 
tion unit as the information data, by formatting the 
digital video and/or digital audio data into a transmis- 
sion format for said physical network. 

4. A network inter-connection node for transmitting infor- 45 
mation data received from one physical network to another 
physical network, comprising: 

a reception unit for receiving a first control message from 
said one physical network, the first control message 
containing an IP (Internet Protocol) address informa- 50 
tion of a data transmission destination, a first header or 
channel information dependent on said one physical 
network, and a layer indication information indicating 
that an information data to be transmitted according to 
the first header or channel information is data in an 55 
upper layer of a protocol layer corresponding to the IP 
address information; 

a first transmission unit for transmitting a second control 
message to said another physical network when the 
reception unit receives the first control message, the 60 
second control message containing the IP address 
information, a second header or channel information 
dependent on said another physical network which is 
obtained from the IP address information, and the layer 
indication information indicating that the information 65 
data to be transmitted according to the second header or 
channel information is data in the upper layer; 
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a memory unit for storing a correspondence between the 
first header or channel information and the second 
header or channel information; and 

a second transmission unit for obtaining the second 
header or channel information corresponding to the first 
header or channel information according to the corre- 
spondence stored in the memory unit when the infor- 
mation data containing the first header or channel 
information is received from said one physical 
network, attaching the second header or channel infor- 
mation to the information data, and transmitting the 
information data to said another physical network, the 
information data containing data of the upper layer 
without IP packet encapsulation. 

5. The network inter-connection node of claim 4, wherein 
the first control message commands a registration of a 
correspondence between the first header or channel infor- 
mation and the second header or channel information, and 

the second control message commands to a receiving 
node or a network inter-connection node for connecting 
said another physical network and a third physical 
network a registration of a correspondence between the 
second header or channel information and a header or 
channel information dependent on said third physical 
network. 

6. A data transmitting node connected with a physical 
network, comprising: 

a first transmission unit for transmitting a control message 
in a case of transmitting information data to a receiving 
node connected with the physical network or another 
physical network, the control message including an IP 
(Internet Protocol) address information of a data trans- 
mission destination, a header or channel information 
dependent on the physical network, and an information 
indicating a required communication resource; and 

a second transmission unit for transmitting the informa- 
tion data containing the header or channel information 
for which the required communication resource is 
reserved, to the receiving node, 

wherein the control message commands to a network 
inter-connection node for connecting said physical net- 
work and a next physical network a registration of a 
correspondence between the header or channel infor- 
mation dependent on said physical network and a 
header or channel information dependent on the next 
physical network for which the required communica- 
tion resource is reserved. 

7. A network inter-connection node for transmitting infor- 
mation data received from one physical network to another 
physical network, comprising: 

a reception unit for receiving a first control message from 
said one physical network, the first control message 
containing an IP (Internet Protocol) address informa- 
tion of a data transmission destination, a first header or 
channel information dependent on said one physical 
network, and an information indicating a required 
communication resource; 

a first transmission unit for transmitting a second control 
message to said another physical network when the 
reception unit receives the first control message, the 
second control message containing a second header or 
channel information dependent on said another physi- 
cal network which is obtained from the IP address 
information, and the information indicating the 
required communication resource; 

an establishing unit for establishing a communication path 
with respect to a receiving node or a next network 
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inter-connection node for connecting said another 
physical network and a third physical network, the 
communication path having the second header or chan- 
nel information with the required communication 
resource; 5 

a memory unit for storing a correspondence between the 
first header or channel information and the second 
header or channel information; and 

a second transmission unit for obtaining the second 
header or channel information corresponding to the first 10 
header or channel information according to the corre- 
spondence stored in the memory unit when the infor- 
mation data containing the first header or channel 
information is received from said one physical 

network, attaching the second header or channel infor- 

• • • 15 

mation to the information data, and transmitting the 

information data to said another physical network. 

8. The network inter-connection node of claim 7, wherein 
the first control message commands a registration of a 
correspondence between the first header or channel infor- 
mation and the second header or channel information, and 20 

the second control message commands to the receiving 
node or the next network inter-connection node a 
registration of a correspondence between the second 
header or channel information and a header or channel 
information dependent on said third physical network. 25 

9. A data transmitting node connected with a physical 
network, comprising: 

a first transmission unit for transmitting a control message 
in a case of transmitting information data to a receiving 
node connected with the physical network or another 30 
physical network, the control message including an IP 
(Internet Protocol) address information of a data trans- 
mission destination, a header or channel information 
dependent on the physical network, and an information 
on a format of the information data to be transmitted 35 
according to the header or channel information; and 

a second transmission unit for transmitting the informa- 
tion data in said format which contains the header or 
channel information, to the receiving node, 

wherein the control message commands to a network 40 
inter-connection node for connecting said physical net- 
work and a next physical network a registration of a 
correspondence between the header or channel infor- 
mation dependent on said physical network and the 
header or channel information dependent on the next 45 
physical network. 

10. A network inter-connection node for transmitting 
information data received from one physical network to 
another physical network, comprising: 

a reception unit for receiving a first control message from 50 
said one physical network, the first control message 
containing an address information of a data transmis- 
sion destination, a first header or channel information 
dependent on said one physical network, and an infor- 
mation on a format of the information data to be 55 
transmitted according to the first header or channel 
information; 

a first transmission unit for transmitting a second control 
message to said another physical network when the 
reception unit receives the first control message, the 60 
second control message containing the address 
information, a second header or channel information 
dependent on said another physical network which is 
obtained from the address information, and the infor- 
mation on a format of the information data to be 65 
transmitted according to the second header or channel 
information; 
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a memory unit for storing a correspondence between the 
first header or channel information and the second 
header or channel information; 

a conversion unit for converting a transmission format of 
the information data to be transmitted from a transmis- 
sion format in the said one physical network to a 
transmission format in said another physical network; 
and a second transmission unit for obtaining the second 
header or channel information corresponding to the first 
header or channel information according to the corre- 
spondence stored in the memory unit when the infor- 
mation data containing the first header or channel 
information is received from said one physical 
network, attaching the second header or channel infor- 
mation to the information data, and transmitting the 
information data to said another physical network. 

11. The network inter-connection node of claim 10, 
wherein the first control message commands a registration of 
a correspondence between the first header or channel infor- 
mation and the second header or channel information, and 

the second control message commands to a receiving 
node or a network inter-connection node for connecting 
said another physical network and a third physical 
network a registration of a correspondence between the 
second header or channel information and a header or 
channel information dependent on said third physical 
network. 

12. The network inter-connection node of claim 10, 
wherein the information data to be transmitted by the second 
transmission unit is MPEG data, and the conversion unit 
converts the transmission format of the MPEG data from a 
transmission format for the MPEG data in said one physical 
network to a transmission format for the MPEG data in said 
another physical network. 

13. A method of data transmission at a data transmitting 
node connected with a physical network, comprising the 
steps of: 

(a) transmitting a control message in a case of transmit- 
ting information data to a receiving node connected 
with the physical network or another physical network, 
the control message including an IP (Internet Protocol) 
address information of a data transmission destination, 
a header or channel information dependent on the 
physical network, and a layer indication information 
indicating that the information data to be transmitted 
according to the header or channel information is data 
in an upper layer of an IP layer; and 

(b) transmitting the information data to the receiving 
node, the information data containing the header or 
channel information and data of the upper without IP 
packet encapsulation. 

14. The method of claim 13, wherein the control message 
commands to a network inter-connection node for connect- 
ing said physical network and a next physical network a 
registration of a correspondence between the header or 
channel information dependent on said physical network and 
a header or channel information dependent on the next 
physical network. 

15. The method of claim 13, further comprising the step 

of: 

(c) receiving digital video and/or digital audio data; 
wherein the step (b) transmits the digital video and/or 

digital audio data received by the step (c) as the 
information data, by formatting the digital video 
and/or digital audio data into a transmission format 
for said physical network. 
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16. A method of data transmission at a network inter- 
connection node for transmitting information data received 
from one physical network to another physical network, 
comprising the steps of: 

(a) receiving a first control message from said one physi- 5 
cal network, the first control message containing an IP 
(Internet Protocol) address information of a data trans- 
mission destination, a first header or channel informa- 
tion dependent on said one physical network, and an 
information indicating that a layer indication informa- 1° 
tion data to be transmitted according to the first header 

or channel information is data in an upper layer of a 
protocol layer corresponding to the IP address infor- 
mation; 

(b) transmitting a second control message to said another 15 
physical network when the step (a) receives the first 
control message, the second control message contain- 
ing the IP address information, a second header or 
channel information dependent on said another physi- 
cal network which is obtained from the IP address 20 
information, and the layer indication information indi- 
cating that the information data to be transmitted 
according to the second header or channel information 

is data in the upper layer; 

25 

(c) storing a correspondence between the first header or 
channel information and the second header or channel 
information; and 

(d) obtaining the second header or channel information 
corresponding to the first header or channel information 3Q 
according to the correspondence stored by the step (c) 
when the information data containing the first header or 
channel information is received from said one physical 
network, attaching the second header or channel infor- 
mation to the information data, and transmitting the 35 
information data to said another physical network, the 
information data containing data of the upper layer 
without IP packet encapsulation. 

17. The method of claim 16, wherein the first control 
message commands a registration of a correspondence 4Q 
between the first header or channel information and the 
second header or channel information, and 

the second control message commands to a receiving 
node or a network inter-connection node for connecting 
said another physical network and a third physical 45 
network a registration of a correspondence between the 
second header or channel information and a header or 
channel information dependent on said third physical 
network. 

18. A method of data transmission at a data transmitting 50 
node connected with a physical network, comprising the 
steps of: 

(a) transmitting a control message in a case of transmit- 
ting information data to a receiving node connected 
with the physical network or another physical network, 55 
the control message including an IP (Internet Protocol) 
address information of a data transmission destination, 

a header or channel information dependent on the 
physical network, and an information indicating a 
required communication resource; and 60 

(b) transmitting the information data containing the 
header or channel information for which the required 
communication resource is reserved, to the receiving 
node; 

wherein the control message commands to a network 65 
inter-connection node for connecting said physical 
network and a next physical network a registration of 
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a correspondence between the header or channel 
information dependent on said physical network and 
a header or channel information dependent on the 
next physical network for which the required com- 
munication resource is reserved. 

19. A method of data transmission at a network inter- 
connection node for transmitting information data received 
from one physical network to another physical network, 
comprising the steps of: 

(a) receiving a first control message from said one physi- 
cal network, the first control message containing an IP 
(Internet Protocol) address information of a data trans- 
mission destination, a first header or channel informa- 
tion dependent on said one physical network, and an 
information indicating a required communication 
resource; 

(b) transmitting a second control message to said another 
physical network when the step (a) receives the first 
control message, the second control message contain- 
ing a second header or channel information dependent 
on said another physical network which is obtained 
from the IP address information, and the information 
indicating the required communication resource; 

(c) establishing a communication path with respect to a 
receiving node or a next network inter-connection node 
for connecting said another physical network and a 
third physical network, the communication path having 
the second header or channel information with the 
required communication resource; 

(d) storing a correspondence between the first header or 
channel information and the second header or channel 
information; and (e) obtaining the second header or 
channel information corresponding to the first header or 
channel information according to the correspondence 
stored by the step (d) when the information data 
containing the first header or channel information is 
received from said one physical network, attaching the 
second header or channel information to the informa- 
tion data, and transmitting the information data to said 
another physical network. 

20. The method of claim 19, wherein the first control 
message commands a registration of a correspondence 
between the first header or channel information and the 
second header or channel information, and 

the second control message commands to the receiving 
node or the next network inter-connection node a 
registration of a correspondence between the second 
header or channel information and a header or channel 
information dependent on said third physical network. 

21. A method of data transmission at a data transmitting 
node connected with a physical network comprising the 
steps of: 

(a) transmitting a control message in a case of transmit- 
ting information data to a receiving node connected 
with the physical network or another physical network, 
the control message including an IP (Internet Protocol) 
address information of a data transmission destination, 
a header or channel information dependent on the 
physical network and an information on a format of the 
information data to be transmitted according to the 
header or channel information; and 

(b) transmitting the information data in said format which 
contains the header or channel information, to the 
receiving node, 

where in the control message commands to a network 
inter-connection node for connecting said physical 
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network and a next physical network a registration of said one physical network to a transmission format in 

a correspondence between the header or channel said another physical network; and 

information dependent on said physical network and (e) obtaining the second header or channel information 

the header or channel information dependent on the corresponding to the first header or channel information 

next physical network. 5 j- ++ u a + ju + u + /\ 

„ A i t r 1 • • i • according to the correspondence stored by the step (c) 

22. A method or data transmission at a network inter- t 4l . r , . ,\ 4 . . 4l i 4l , 

, r A . r , A ... when the information data containing the first header or 

connection node tor transmitting inrormation data received , , . r .. i • i 

r u • i + i + +u u • i + i channel mlormation is received Irom said one physical 

Irom one physical network to another physical network, i i • r 

comprising the steps of: network, attaching the second header or channel infor- 

, . .. _ , „ i • 1 n mation to the information data, and transmitting the 

(a) receiving a nrst control message Irom said one physi- IU . r A . , A A . , ^ t . , , 

v 7 , A i A i £ A .i . • • inrormation data to said another physical network, 

cal network, the nrst control message containing an „ , , „ , . , r . J . _ , 

AA • r + . p A + + • • j +• T- 23. Ihe method or claim 22, wherein the nrst control 
address inrormation or a data transmission destination, 

a first header or channel information dependent on said messa § e commands a registration of a correspondence 

one physical network, and an information on a format between the first header or channel ^formation and the 

of the information data to be transmitted according to 15 second header or channel information, and 

the first header or channel information; the second control message commands to a receiving 

(b) transmitting a second control message to said another node or a network inter-connection node for connecting 
physical network when the step (a) receives the first said another physical network and a third physical 
control message, the second control message contain- network a registration of a correspondence between the 
ing the address information, a second header or channel 20 second header or channel information and a header or 
information dependent on said another physical net- channel information dependent on said third physical 
work which is obtained from the address information, network. 

and the information on a format of the information data 24. The method of claim 22, wherein the information data 

to be transmitted according to the second header or to be transmitted by the step (d) is MPEG data, and the step 

channel information; ( e ) converts the transmission format of the MPEG data from 

(c) storing a correspondence between the first header or a transmission format for the MPEG data in said one 
channel information and the second header or channel physical network to a transmission format for the MPEG 
information; data in said another physical network. 

(d) converting a transmission format of the information 

data to be transmitted from a transmission format in the * * * * * 
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Mail Stop Amendment 
Commissioner for Patents 
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Alexandria, VA 223 13-1450 



I, John Houston, hereby declare and state: 

1 . I am the named inventor of U.S. Patent 6,353,929 ("my patent"). As 
such, I am very familiar with the content of my Patent. 

2. Because of that familiarity, i have been asked to independently review 
U.S. Patent Application Serial No. 09/909,224 (the ut 224 application' 7 ), 
the claims of the'224 application as presented herewith, the rejections 
made in the final Office action mailed on August 1 , 2007, Ozkan, U.S. 
Patent 6,03 1 ,577, and the applicants' arguments filed June 28, 2007. I 
have reviewed these materials and am presenting this declaration to 
support the applicant's request for a continued examination, and to assist 
the USPTO in its examination of the '224 application. 
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3. I have reviewed the final Office action's argument that my patent is 
directed toward a tuning device. However, I respectfully submit that the 
Examiner misunderstands my disclosure when he describes it as a tuning 
device. My patent is directed toward an audience measurement system. It 
is not a tuning device and it does not seek to affect how audience members 
utilize their tuning devices nor does it seek to affect how such tuning 
devices operate to tune programs. Instead, specifically with respect to 
tuning devices, my patent relates to measuring how audience members 
utilize their own tuning devices. As such, there is no reason apparent to 
me to modify my patent to enable tuning of any sort, let alone to enable 
tuning "to sub-channels without acquiring the program map table (PMT)"' 
as stated in the Office action. 

4. The cooperative media handler methods disclosed in my patent provide 
access to a rich amount of audience measurement data, so there is nothing 
to be gained by employing eavesdropping methods such as those disclosed 
in the "224 application when my disclosed methods are available. 
Therefore, in my opinion, a person of ordinary skill in the art reading my 
patent in the relevant time frame would not be led by my disclosure to the 
invention recited in claims 62 and 80 of the '224 application as currently 
presented in the response to the Office action of August L 2007 filed 
herewith. Quite simply, the techniques I disclose and the techniques 
recited in claims 62 and 80 relate to fundamentally different approaches to 
media measurement. Since my patent has no need of eavesdropping 
techniques such as those recited in claims 62 and 80, in my opinion, no 
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person of ordinary skill in the art reading my patent would take it as 
suggesting the eavesdropping techniques of the '224 application. 
5. With respect to independent claims 1 3, 61 and 79 of the '224 

application as presented with the Response to the Office action o fAugust 
1, 2007 filed herewith, my patent makes absolutely no mention of 
collection and/or timestamping FID headers as a useful vehicle for 
performing media monitoring. While it is true that the methods and 
apparatus disclosed in my patent could certainly collect such PID headers 
(the methods and apparatus I disclosed can be used to collect virtually any 
type of media measurement data), my patent does not speci fically disclose 
the concept of collecting and/or timestamping such PID headers or in 
anyway indicate that collecting and/or timestamping such PID headers 
would be of interest. Therefore, in my opinion, the only way a person of 
ordinary skill in the art at the relevant time frame reading my patent would 
be led to collect and timestamp PID headers, is if that person had a priori 
knowledge of the value of collecting such PID headers from another 
source. 

6. I agree with the position that my patent described collecting payload 
data which may be associated with PID headers and, thus, my patent does 
not by itself motivate someone to collect and timestamp PI D headers. 
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7, I understand that willful and false statements and the like are 

punishable by a fine and/or imprisonment under 18 U.S.C. § 1001, and 
that any such willful and false statement may jeopardize the validity of this 
application and any patent resulting therefrom. 



Date: f h3&~6f 
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